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>
>> > 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.
Received on 2015-06-15 17:36:58 CEST