On Tue, Aug 30, 2011 at 8:17 PM, Neels J Hofmeyr <neels_at_elego.de> wrote:
> 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'll get pedantic here and point out that while your first statement
may be true for FSFS specifically, it is not true for a more general
solution. You essentially state that "if we don't want writers to
block readers, FSFS should be read-only, append-only." But the
property of read-only, append-only is not a strict requirement for
non-blocking writers. (This requirement may exist for FSFS, but the
world is quite a bit larger than just FSFS. :) )
In other words, there exist systems in which writers don't block
readers that use strategies other than read-only, append-only.
Row-level locking in an RDMS comes to mind. While I know this thread
is specifically about FSFS, let's keep our minds open. :) <insert
plea to not reinvent the database here>
I'll also note that FSFS writers *do* block readers for a short period
(the "serialization window"), so the problem is actually one of
minimizing the length of time the process spends in the window, not
doing away with it entirely.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-31 15:56:15 CEST