On Tue, 2006-03-07 at 11:55, David Brown wrote: > > > > All you'll do by trying is lose the atomic nature of the hardlinks. > > You aren't ever going have the data at the same time you know all > > of it's names so you can store them close together. Just throw in > > lots of ram and let caching do the best it can. > > Any reasonable SQL database would do this very well. Doing operations > atomically is fundamental, and indexing diversely added data is an > important feature.
The piece that has to be atomic has to do with the actual pool file, so unless you move the data into the database as well you can't atomically manage the links or ever be sure that they are actually correct. And if you move the data in, I suspect you'll find that databases aren't as efficient as you thought. > The caching doesn't generally help at all, because the nodes are only > touched once, and that is very out of order. Add enough RAM to hold the pool inodes. That's what your SQL vendor is going to say about the database too. -- Les Mikesell [EMAIL PROTECTED] ------------------------------------------------------- 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/
