On Fri, Apr 25, 2008 at 12:38:59PM -0400, C. Scott Ananian wrote: > On Fri, Apr 25, 2008 at 12:30 PM, Joshua N Pritikin <[EMAIL PROTECTED]> +wrote: > > > If you use BDB correctly, it seems to me to be pretty solid and mature > > > -- a conclusion which concurs with the long list of BDB users. > > > > Sure, but BDB would be even more trustworthy if I could 'rm -rf' the > > database and regenerate it from scratch without losing data. If metadata > > was stored in POSIX xattrs then it would seem like your design permits > > this mode of operation. > > Yes, it does, but I doubt we'd want to waste precious NAND space on > storing this data redundantly. Perhaps.
Fair enough. At least the option is there. > > I have seen enough instances of "foolproof" databases that I think we > > should minimize reliance on them. > > Yes, certainly I refuse to use GMail because there's a database behind > it. Or Firefox for that matter. Or Linux, since it maintains many > internal databases, and they're not even standard well tested > userspace ones! And don't get me started on resierfs. Or ext2. Or > ext3! I'm not trying to give you a hard time. All I'm saying is that it might be worth the disk space cost of making the data redundent and self-contained in order to avoid potential support issues in the future. For example, if some kid in the middle of nowhere starts complaining that the journal doesn't work, do you want to tell him that he has to recover from backup or tell him to simply click a hypothetical control panel button to rebuild the journal index? Or are you willing to bet that the failure rate of OLPCFS will be much less frequent than the failure rate of the NAND? Somebody should try to qualify how much disk space is actually at stake. What is the disk cost of storing the metadata (but not the index of the metadata) twice? If it really takes a lot of disk then maybe just store some of the metadata twice. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
