linux-admin.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris DiTrani <cditrani@livedata.com>
To: fluca1978@infinito.it
Cc: linux-admin@vger.kernel.org
Subject: Re: zip error: out of memory
Date: Thu, 29 Jul 2004 10:20:45 -0400	[thread overview]
Message-ID: <1091110844.27376.57.camel@chris.livedata.com> (raw)
In-Reply-To: <200407291511.15582.fluca1978@infinito.it>

On Thu, 2004-07-29 at 09:11, Luca Ferrari wrote:

> 
> Here's the command line I use:
> 
> /usr/bin/zip  -r -u -y -b /tmp/backup  /mnt/disco2//letizia.zip * 
> 
> zip error: Out of memory (allocating temp filename)
> 
> and the memory as reported by free before and during the zipping:
> 
>              total       used       free     shared    buffers     cached
> Mem:        256624     253180       3444          0      40412      85796
> -/+ buffers/cache:     126972     129652
> Swap:      1020088         16    1020072
> 
>              total       used       free     shared    buffers     cached
> Mem:        256624     254096       2528          0      34604      92080
> -/+ buffers/cache:     127412     129212
> Swap:      1020088         16    1020072
> 

Nothing unusual here.

I had misread your original post as zipping from an NTFS partition. If I
hadn't I would have said that the interaction with NFS is probably the
root cause of your trouble and you should use a different strategy.

As a quick work-a-round you could use tar or rsync to get a copy of the
nfs mount on local disk and zip it from there. I've done both for much
larger NFS mounts without trouble.

A more ideal strategy might be to do the zip on the machine that hosts
the nfs mount and transfer the zip file via ftp or rsync.

FWIW, my strategy for backup is to have a backup machine running rsync
as a service. Any machine that has data to backup does a:

rsync -az --delete /local-tree-to-backup/ \
rsync://backup-machine/backup-dir

This creates a snapshot of the backup source on the backup machine. I
then compress the snapshot and store it, leaving the snapshot in place
so that the next time a machine does the rsync maneuver only the diffs
are sent, making the process much more efficient on an ongoing basis.
The down side is you need disk space to keep the snapshots around, but
even if you don't, rsync with the -z option compresses the data before
sending it over the network, so it's much better than grabbing the whole
thing uncompressed over NFS.


CD



  reply	other threads:[~2004-07-29 14:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-28 15:35 zip error: out of memory Luca Ferrari
2004-07-28 19:40 ` Chris DiTrani
2004-07-29 17:06   ` Glynn Clements
2004-07-28 20:17 ` chuck gelm
2004-07-29 13:11   ` Luca Ferrari
2004-07-29 14:20     ` Chris DiTrani [this message]
2004-07-29 21:57     ` chuck gelm
2004-07-30  8:50       ` Luca Ferrari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1091110844.27376.57.camel@chris.livedata.com \
    --to=cditrani@livedata.com \
    --cc=fluca1978@infinito.it \
    --cc=linux-admin@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).