On Mon, Nov 19, 2012 at 7:30 PM, Ben Reser <b...@reser.org> wrote: > On Mon, Nov 19, 2012 at 6:43 AM, Stefan Fuhrmann > <stefan.fuhrm...@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 *
