subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: Efficient and effective fsync during commit
Date Tue, 16 Jun 2015 21:01:36 GMT
On Mon, Jun 15, 2015 at 5:36 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:

> On 12 June 2015 at 15:11, Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>
> wrote:
> > On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:
> >>
> >> On 29 May 2015 at 18:55, Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>
> >> wrote:
> >> > If you assume / suspect that FlushFileBuffers() only
> >> > operates on the open handle, i.e. only flushes those
> >> > changes made through that thandle, then you assume
> >> > that our commit process is seriously broken:
> >> >
> >> > For every PUT, we open the protorev file, append the
> >> > respective txdelta and close the file again. Since the
> >> > final flush uses yet another handle, this implies that
> >> > most of the revision data in each rev file does not get
> >> > fsync'ed and may be lost upon power failure.
> >> >
> >> > You might be right. So, if you care about repository
> >> > integrity, you should use your MSDN subscription and
> >> > ask MS for clarification on FlushFileBuffers() behaviour.
> >> You also may request MSDN subscription and ask MS for clarification or
> >> keep Windows code as it was before.
> >
> >
> > To be clear: You are proposing that the code on Windows
> > is fundamentally broken (revision contents not being
> > committed) while I think we "only" have a persistence
> > issue with renames. Since your business depends on
> > you being wrong, it would be in your best self-interest
> > to go and find out ...
> >
> > Of course, I could apply for an MSDN subscription, wait
> > for it be approved etc. but I think it would be fairer if you
> > could check the Windows side of things while I try to get
> > some answers for POSIX.
> >
> Am I understand you properly, that *your business* does not depend on
> Windows and you just do not care about this? You are wrong if you
> think this way. Please try to imagine what will happen if a Windows
> developer broke/slowdown the code on Unix and then just ask Unix
> people to fix their problems, because it is their business.
>
> Please elaborate if I get your position wrongly.
>

It boils down to 3 points:

Burden of proof. If someone makes a claim, it is their
responsibility to provide evidence. My claim is "we need
to fsync after rename". You made an independent claim
"fsync after close does not flush all contents". We both
have to provide evidence (or say that we can't right now,
or kindly ask others to help, or ...)

Cooperation. I spent a few days researching the both
issues and came up with evidence (arguments can be
evidence as well) in support of my claim and counter
to your claim. So, I did work for *both* of us. It is perfectly
fine to not be convinced by the evidence and e.g.
require confirmation by a "higher authority". Then I
provided you with input for the kind of information you
would need to ask MS to either prove or disprove *your*
claim as well as *mine*. Finally, I offered to handle
the POSIX side of both claims on my own and asked
you to file the incident at MS. To me, this looks like
a lot of input on my part and not like ignoring anybody
or anysystem.

Self-interest. This is the part that completely puzzles me.
I don't meant it as an allegation; it is just the part where I
simply don't get you. Like, at all. If *my* livelihood would
depend on the quality of a certain product on a specific
platform and if then I would suspect a major flaw in its
transaction handling, I would try to at least figure out
how bad things are. And I would want to know it asap.
If I didn't have the time to investigate right away or if
I thought that the issue isn't urgent, I might say so and
ask for people's help in the meantime.

The last point is the critical one, IMO. It prevents me
from understanding you and has lead to needless fights
in the past. I feel this is something we need to talk
about privately in Berlin.

-- Stefan^2.

Mime
View raw message