On Fri, May 29, 2015 at 4:54 PM, Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com>
wrote:
> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
>
> > However, it does not tell you anything about consistency with outside
> > parties, say some svnsync'ed repository. The problem is that Windows may
> > end up not persisting the rename (of e.g. the 'current' file) after
> telling
> > the client that the commit got through and a new revision number is
> > available.
>
> [...]
>
> > The two problems are mentioned: The first one is that rename itself is
> > obviously not persistet, e.g. the 'current' file may show the old
> contents
> > even after the server send a "commit done, new rev available" to the
> client.
> >
> > To reproduce: Have a "busy" server setup, do lots of commits, record HEAD
> > revs returned to the client on the client, pull the plug on the server
> and
> > compare HEAD on server vs. HEAD on client. In some cases, the latter
> should
> > be higher.
>
> [...]
>
> This reproduction contradicts with what I see in code. Is it a blind
> guess?
> Did you try it with this patch and without it? Our current code doesn't
> use
> the svn_fs_fs__move_into_place() when updating the db/current file
> contents,
> so I don't see how it could possibly fix the aforementioned problem.
You are right, the 'current' file uses yet another instance
of that non-sync'ing code. I hadn't checked that before
I wrote the reply.
If that would be fixed, the same issue with the revision
data file and the revprops file still exists. The resulting
behaviour would be the one described (error due to
missing file).
> Do we
> *really* have a reproducible problem with single-volume renames on Windows?
>
Let me ask you this: Is a rename under Windows (past
and future releases) an immediately persistent operation?
IOW, do you observe 10+ms delays for your RAID to
complete the I/O before the call returns?
If there is a problem with how we handle cross-volume moves, then we should
> fix it, but perhaps not with doing a huge amount of unnecessary
> CreateFile()
> and FlushFileBuffers() calls in a common case in order to solve an edge
> case.
>
For FSX, I'll revamp the commit file handling such that
cross-volume renames should no longer be an issue
while reducing the overhead to a single fsync wait time.
It should also do away with the plethora of "sync here"
and "rename there" calls currently sprinkled over the code.
Once that works, it should be straight-forward to port it
to FSFS.
-- Stefan^2.
Received on 2015-06-12 13:42:34 CEST