You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2005/09/29 20:20:19 UTC
FSFS locking and the impossibility of online obliteration
Recently, I've made legacy BDB-related locking code in libsvn_repos not
apply to FSFS repositories.
I believe that it was always a design goal of FSFS for readers to do no
locking.
However, a consequence of finally meeting this goal is that it will be
impossible to ever implement race-safe online obliteration for FSFS
repositories.
Is this ok?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS locking and the impossibility of online obliteration
Posted by Greg Hudson <gh...@MIT.EDU>.
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
data.
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
Re: FSFS locking and the impossibility of online obliteration
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 9/29/05, Ben Collins-Sussman <su...@red-bean.com> wrote:
> My conception of 'svnadmin obliterate' was that it would it would
> *require* disabling all access to the repository. Maybe it's
> something we discussed previously, maybe it was just an assumption of
> mine.
I don't have strong feelings one way or the other about this, but for
the record Perforce's "p4 obliterate" command does not require
exclusive access to the repository.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS locking and the impossibility of online obliteration
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 29 Sep 2005 15:51:54 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> I think it's okay. If someone wants instantaneous effectiveness in
> obliterate, they'll have to shut down the server first, that's all.
My conception of 'svnadmin obliterate' was that it would it would
*require* disabling all access to the repository. Maybe it's
something we discussed previously, maybe it was just an assumption of
mine.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: FSFS locking and the impossibility of online obliteration
Posted by kf...@collab.net.
"Max Bowsher" <ma...@ukf.net> writes:
> Recently, I've made legacy BDB-related locking code in libsvn_repos
> not apply to FSFS repositories.
>
> I believe that it was always a design goal of FSFS for readers to do
> no locking.
> However, a consequence of finally meeting this goal is that it will be
> impossible to ever implement race-safe online obliteration for FSFS
> repositories.
>
> Is this ok?
I think it's okay. If someone wants instantaneous effectiveness in
obliterate, they'll have to shut down the server first, that's all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org