An olpcfs experience report

[Joshua N Pritikin]

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 <jpritikin at pobox.com>
+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.