On Tue, Mar 07, 2006 at 12:15:50PM -0600, Les Mikesell wrote: > 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.
There are no links. Each file has one entry, under the pool directory. All that has to be managed is creation and deletion of these files. It is not difficult to be able to easily recover from a crash in either of these scenarios, as long as ordering is done right. > > 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. It doesn't help. I have plenty of RAM. The problem is that over the course of the day, the pool nodes leave the cache. Then, next pool scan, they get fetched, in a very out-of-order fashion. 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/
