On Thu, Mar 09, 2006 at 06:31:51PM -0800, Matt wrote: > Wouldn't it be better to keep the directory structure of the > (compressed) files and keep hash and attributes in the DB? After all, > this is how the data are received and how they will be accessed during > a restore.
Even that isn't all that important. Just store the files into the pool in the order they are traversed. The DB stores hashes and attributes (and the real tree). Each new file, after storing it, has a full hash computed, and the DB checked. If it is unique, leave it, if new, delete the file, and update the DB. Since the DB maintains the mapping, the names don't need to be very interesting, I was thinking something like 1 2 3 4 5 6 7 8 9 1x/10 11 12 13 14 15 16 17 18 19 2x/20 21 .. 9x/98 9x/99 1x/1x/00 or some other traversal where the names get deeper as the numbers get longer. On something like reiserfs (especially reiser4) there isn't much particular reason to not just put all of the files in a single directory (at least according to them). 'ls' might struggle with that, though. By storing the files in the same order as the traversal, they will likely stay near files that will be retrieved at a similar time. Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/backuppc-users http://backuppc.sourceforge.net/