RE: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: zaterdag 18 mei 2013 10:52
> To: Subversion Development
> Subject: Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
>
> On 18.05.2013 08:55, Bert Huijben wrote:
> > I see all those easy +1’s on other operating systems...
> > I assume you all reproduced the problem on Windows???
>
> What the blazes are you going on about, Bert? Justin's +1 was for
> putting repository integrity before performance. That has nothing at all
> to do with any specific platform.
>
> > Maybe also on actual hardware instead of a VM (with a VM harddisk
> > emulation infrastructure with different powerfail handling)?
> >
> > I still see no prove that the symptoms are not in this category!
>
> Ivan's analysis of the failure mode is correct, and it has nothing to do
> with disks, emulated or otherwise, because it is a side effect of what
> happens before the data hits the disk driver layer.
>
> > But if you check the sqlite research: which other operating systems
> > provide the same guarantees on power failure at the cost of a lot of
> > performance?
>
> The SQLite docs clearly spell out what happens if you don't turn on the
> whole sync'd WAL. The Subversion repository is not an application-level
> persistent store, it's a centralized repository that we /know/ has to be
> as robust as we can make it.

But why do we perform the same flush for 3* on a tempfile for each property conflict that is postponed in 'svn'?

For files that aren't read back unless the user uses interactive conflict resolution?

This kind of behavior belongs in FSFS... well designed, not in a simple 'cheap' function to write a string to a file.

I 100% agree that FSFS should be robust...

But if we add a flush after every file write in our code nobody will use Subversion as it is so insanely slow... And we wouldn't resolve the problem we thought of resolving.

Getting proper revision commit handling requires a careful design and applying that. Not adding explicit flushes in low level functions that are used for more code paths than these.

The careful flush is needed at the time of committing a revision. Probably two or three times max during a revision creation. This flush will require writing to two MFT's (Master File Tables) and the file itself so probably at least 6 harddisk spin cycles each (and more if there are other operations waiting for the MFT to be completed stable). If the disk is not locally but on another Windows system the CIFS protocol will transfer the ensurance further and the delay may be much larger.

If we apply this same flush to the average tempfile that isn't even referenced from other files we'll trash performance for nothing. And that is exactly what you get if you do this low level in io.c, without also handling the move/rename in the same function.

We do this because *some of* the callers want this behavior... But all others get the same pain as well.

And then the rename function can just perform a dumb file copy without any precautions when we are crossing a disk boundary.

This behavior belongs in a function with a specific purpose: atomic renames of new files.
Not in a simple file creation function that is used in many places.

        Bert
Received on 2013-05-18 11:53:15 CEST