On Mon, Nov 19, 2012 at 7:30 PM, Ben Reser <ben_at_reser.org> wrote:
> On Mon, Nov 19, 2012 at 6:43 AM, Stefan Fuhrmann
> <stefan.fuhrmann_at_wandisco.com> wrote:
> > A crashed writer process may leave a corrupt protorev and / or
> > other incomplete files. There is no atomic incremental change
> > here. The caller (client) using the crashed process is supposed
> > to detect the crash and abandon the transaction.
>
> I don't think that "supposed to" is documented anywhere (unless you
> want to consider our clients behavior as documenation). After dealing
> with the stuck being_written flag that produced rep_write_cleanup, I
> don't think we should assume that going forward.
>
Seems that failure scenarios are not very will documented
in general. We often rely on "DtRT" without actually working
out what that thing might actually be.
> It may not be worth dealing with in fsfs but within fsfs2 I think we
> should make representation operations even to the protorev files (or
> whatever their equivalent is) be atomic. Especially since these
> operations are usually driven across separate HTTP requests when we're
> using DAV.
>
Noted.
> Then again, beyond improving repo consistency in some edge cases it'd
> also allow us to support parallelizing the PUTs. There may be other
> issues I'm not aware of off the top of my head in doing that right
> now, but at least in fsfs it's absolutely not supported since for the
> entire duration of the PUT you have the protorev file locked.
>
Since I'd like to attempt some support for concurrent commit
(e.g. for svnadmin load), I / we may stumble across some
approach that tackles the consistency issue for FSFS already.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Received on 2012-11-25 22:25:54 CET