[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] Re: [Duplicity-talk] Pretty pictures and new ve
From: |
John Goerzen |
Subject: |
Re: [rdiff-backup-users] Re: [Duplicity-talk] Pretty pictures and new version of proposal |
Date: |
Mon, 29 Sep 2003 14:21:42 -0500 |
User-agent: |
Mutt/1.4i |
On Mon, Sep 29, 2003 at 08:06:08PM +0100, Kevin Spicer wrote:
> > fine with listing the archives in the old-fashioned (tar) way? Can most
> > tape drives even seek to the start of the index file at all?
>
> I think that was the point of having two copies was so that streaming
> media could content itself with reading the data from the blocks, and
> not worry about having to somehow get the index
Yes. The information should only be there.
> > For the sparse file support, I wonder if it might better to leave it out
> > and assume that anybody with large sparse files (and the common sense of
> > tofu) would think to encode the inner file with a compression method.
>
> Thats fine, as far as storage is concerned, but doesn't that bloat the
> files when restored? (I'm not very clued up on sparse files so
> apologies if I've missed something)
Yes; sometimes significantly. Some platforms often use sparse files for
binaries, core dumps, and other things -- so they are more prolific than you
might imagine. Imagine the hapless system administrator who finds that the
/usr partition is no longer large enough to hold his system files upon
restoring them from tape, though they're the exact same files that were
there before :-)
A sparse file is created on Unix systems by seeking past the end of the
file's data and writing data there. The system does not actually allocate
space on-disk for the intervening blocks, and when read back later, simply
supplies a stream of NULLs for that area.
-- John