RE: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 18 May 2013 11:52:07 +0200
> -----Original Message-----
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.
This is an archived mail posted to the Subversion Dev mailing list.