Re: Efficient and effective fsync during commit

On 12 June 2015 at 15:11, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
> On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>
>> On 29 May 2015 at 18:55, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
>> wrote:
>> > On Fri, May 29, 2015 at 4:14 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> >> On 28 May 2015 at 20:47, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
>> >> wrote:
>> >>> Hi all,
>> >>>
>> >>> Most of us would agree that way we fsync FS changes
>> >>> in FSFS and FSX is slow (~10 commits / sec on a SSD,
>> >>> YMMV) and not even all changes are fully fsync'ed
>> >>> (repo creation, upgrade).
>> >>>
>> >> The first question is it really a problem?
>> >
>> > Recently, we had customers wondering why their servers
>> > wouldn't serve more than 20 commits/s (even on enterprise
>> > SSDs and with various OS file system tuning options).
>> > With QA bots constantly creating snapshots and tags,
>> > there isn't too much head room anymore.
>> >
>> Ack. Was it Windows or Linux?
>
>
[...]

>> > 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.

[...]

-- 
Ivan Zhakov