rdiff-backup-users
[Top][All Lists]
Advanced

[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: Kevin Spicer
Subject: Re: [rdiff-backup-users] Re: [Duplicity-talk] Pretty pictures and new version of proposal
Date: 29 Sep 2003 20:06:08 +0100

On Mon, 2003-09-29 at 19:35, Will Dyson wrote:

> I wonder if the need for two copies of the metadata could be avoided by
> having the index file only contain pointers to the actual metadata
> stored at the beginning of each file.
> 
> This would make it harder to list the contents of the archive, since
> lots of pointer chasing would be needed. Particularly a problem with
> streaming media. But perhaps most folks with archives on tape would be
> 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

> 
> I like how putting the directory contents only in the index's version of
> the meatadata solves the problem of having to know the offsets of files
> yet to be written. That is an argument for the redundant metadata.

If I understand correctly we are not talking about redundant metadata,
only index data.

> 
> 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)




BMRB International 
http://www.bmrb.co.uk
+44 (0)20 8566 5000
_________________________________________________________________
This message (and any attachment) is intended only for the 
recipient and may contain confidential and/or privileged 
material.  If you have received this in error, please contact the 
sender and delete this message immediately.  Disclosure, copying 
or other action taken in respect of this email or in 
reliance on it is prohibited.  BMRB International Limited 
accepts no liability in relation to any personal emails, or 
content of any email which does not directly relate to our 
business.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]