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/
