[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS locking and the impossibility of online obliteration

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-09-29 23:57:32 CEST

On Thu, 2005-09-29 at 21:20 +0100, Max Bowsher wrote:
> However, a consequence of finally meeting this goal is that it will be
> impossible to ever implement race-safe online obliteration for FSFS
> repositories.

I think we could get close.

Atomically replace all the rev files which refer to the obliterated
data, then atomically replace the rev file containing the obliterated

That algorithm would fail if a reader is going down a delta chain as the
obliterator is working, and the obliterator starts behind the reader but
then manages to get ahead of it. In practice, such a failure is
unlikely since the obliterator will be much slower than a reader. But,
we could perhaps handle such failures by having the reader retry if it
runs into obliterated data. (If we're re-marshalling the old rev file
in order to save space, detecting this case might have to be inelegantly
heuristic, although there are ways to make it more sound.)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 30 00:04:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.