On Tue, Aug 30, 2011 at 8:17 PM, Neels J Hofmeyr <ne...@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/
