John Szakmeister writes:
>
> BTW, I believe this very problem is part of the reason that we're
> seeing corruption periodically with FSFS. One concern I have is
> how will clients handle this situation. I mean, they don't
> necessarily know that there is more than one process handling the
> request, right? How is the error going to be communicated back,
> and how will the clients handle it? Are they all of a sudden going
> to start experiencing random failures on commit? I'm just trying
> to understand the situation, since we're avid users of
> mod_dav_svn. :-)
>
I've got a simple idea how to protect against this problem. It
requires APR to actually return write errors, but using an APR that
doesn't can never guarantee that what you wrote wil actually be stored
in the repository.
The idea is to create a file, let's all it, "INUSE" whenever we are
going to write to the revision prototype file. This file is created
with the exclusive file and removed when the representation is closed
(svn_stream_close is called on the writable stream).
This means that an error will leave the INUSE file behind, preventing
any further writes to the transaction. (Yes, this is the same locking
strategy used in libsvn_wc:-)
The point is to actually leave the lock around on failure, which file
locking doesn't do. I don't think this has any performance problems.
We already open/seek/write/close the revision prototype file for each
modified repository file and write a node revision file.
Thoughts?
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 2 22:19:10 2006