On 12 June 2015 at 15:11, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> wrote: > On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 29 May 2015 at 18:55, Stefan Fuhrmann <stefan.fuhrm...@wandisco.com> >> wrote: >> > On Fri, May 29, 2015 at 4:14 PM, Ivan Zhakov <i...@visualsvn.com> wrote: >> >> On 28 May 2015 at 20:47, Stefan Fuhrmann <stefan.fuhrm...@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
