duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 20.10.2009 22:13, Kenneth Loafman wrote:
> edgar.soldin@xxxxxx wrote
> > > Not sure that keeping the sig files is the way to go as a default
> > > option, and we'd run into the same problems as --archive-dir if we make
> > > it optional.
> > >        
> > currently keeping sig files is no option, or? So it's a whole different
> > scenario, isn't it?
> >      
> Not really all that, but the root problem with options like this is that
> we don't store them in a configuration file for reuse.  If we did, then
> a lot of problems would be solved.
>    

that's why there are frontends to the mighty magic of duplicity storing 
the options. Again .. right now simply enable the keeping of the sig 
files would do no harm. It would take up more space,  while enabling the 
user to list the contents of the chain much faster. Right?
So why does the user keep a chain if he/her doesn't want to use it at 
some point?

I just looked and found a sigtar for a 4,5TB full 69MB in size. Small 
incrementals 40 KB in size seem to have equally sized sigtars. Whats the 
logic behind these sizes?

And if the sig is nearly the same in size as the incremental, why keep 
it seperate? What information is in the sig that couldn't be put in the 
data tar as well. AFAIU the significant advantage is the sigtars size, 
which doesn't seem to be true for small incrementals.

> > > The first run without the option and the previous sigs
> > > would just disappear.  Sure to generate lots of complaints.
> > >        
> > what's the downside on keeping the small sig files for each chain?
> >      
> For one, they aren't that small, and some folks pay a bunch for offsite,
> so want as little overhead as possible.  It's all a tradeoff.
>    

it always is .. but again what use are old chains if they are not 
listable performantly and therefore usable at all.

> One thing to think of is allowing the signatures to cover a larger
> block.  Right now, the blocksize that a sig covers is fairly small,
> matching what rdiff does, but we could make that tuneable.  If you make
> the coverage larger, you get fewer sigs per file and smaller sigtar
> files, but larger blocks are backed up.  The opposite produces larger
> sigtar files.  For now, its a good mix, but it would be better if you
> could tune it with knowledge of your backup needs.
>    

Sorry, I was under the impression that sig files simply hold checksums 
for data vol files and a list of their contents. Is there more about it? 
Could you explain?


...ede