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
next prev parent 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).