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
>
Received on 2011-08-31 12:40:36 CEST