Jeffrey J. Kosowsky wrote:
>
> However, collisions are pretty easy to deal with.
> Also, my suggestion was to do this on a selective basis -- say "large"
> files when backing up over a slow link, so it would not necessarily
> involve "millions" of files.

If you can't map the hash you get to the filename you have to search the 
whole pool, and if that doesn't have millions of files you won't have 
much chance of a random new match.

> The big problem would be
> that the partial file md5sum used to define pool file names is not
> consistent with the rsync checksum calculations -- which all goes back
> to my thinking that long-term, a relational database is a better
> structure for storing backup information than the "kludge" of
> hard-links plus attrib files. 

I wouldn't call using the inherent properties of a unix filesystem to 
store files in a convenient way a "kludge".  It is something that has 
been developed and optimized even longer than relational databases.

> In this case, relational database, would
> allow for pool lookup based on rsync mdsums (as well as the existing
> partial md5sums).

Yes, you could keep multiple keys and indexes in a database but there is 
no reason to think it would be more efficient, and unless the file 
contents are also stored in the database you introduce the problem that 
changes to the databased keys aren't atomic with the files themselves.

-- 
   Les Mikesell
     lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/