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...
A new format doesn't solve the underlying separation -- unless it's niftier
than me.
~Neels
Received on 2011-08-31 03:18:08 CEST