Neels J Hofmeyr wrote on Wed, Aug 31, 2011 at 03:17:26 +0200: > On 08/30/2011 06:34 PM, Hyrum K Wright wrote: > > In reading through this, as well as the discussion in IRC, I'm once > > again wondering why we're bolting this stuff onto the outside of FSFS > > rather than rethinking the entire FS problem (along with things like > > obliterate and move-to storage and ...). I realize we can't do > > *everything*, but these feels strangely like libsvn_wc from 5 or 6 > > years ago. Is there a compelling reason to reinvent the database? > > I know nothing of other extensions to the fsfs database, but this is how my > thought process early-outed from suggesting an all-new fsfs db because of > successors: > > A large part of FSFS should be read-only, grow-at-the-end-only, so that we > don't need to lock out readers while writing. However, successors are little > bits of info *later* added to random spots of the big read-only part, like > dusty strings continuously growing off of the impenetrable wall of > revisions, as new solid revision bricks sprinkle successor ids from the top. > No matter how we wriggle it, the successors will probably always be stored > separately, of sorts bolted on to the RO part... >
I don't follow. Storing a noderev's successors in a file named after the noderev's id would be append-only; the problem here is that we'll have tons of writeable files, not that the writeable files won't be append-only. > A new format doesn't solve the underlying separation -- unless it's niftier > than me. > > ~Neels >
