fsync()-in webdav PUT

[Richard Demeny]

This needs to stop

On Monday, March 5, 2018, Nagy, Attila <bra at fsn.hu> wrote:

> On 03/05/2018 12:54 PM, Reinis Rozitis wrote:
>
>> Jesus, why? You start the fsync in a thread and you wait for it to be
>>> completed
>>> with the HTTP response. Until this happens, the main thread can service
>>> other
>>> requests.
>>> Have you ever seen an async program which uses threads to run blocking
>>> operations?
>>>
>> The point was that it's odd that you are going to "trust" the userland
>> daemon to finish the sync operation (which obviously has the possibility to
>> fail) in some background thread while not trusting the OS/kernel to do the
>> buffer/vm/pagecache flush at some "later" / "better" time (which you can
>> even finetune to do it immediately - vm.dirty_ratio /
>> vm.dirty_expire_centisecs etc).
>>
> The point here is you are completely on the wrong track. I'm not talking
> about a "background thread".
> I was talking about:
> 1. placing the WHOLE PUT operation into its own thread OR
> 2. placing just the fsync into a thread (and waiting it to complete with
> the HTTP response of course)
> (or doing something equivalent, which won't block nginx's main thread)
> This means the HTTP success or fail response will only be given back AFTER
> the fsync was successfully completed.
>
> There is absolutely no problem with a failing fsync. It means the
> operation couldn't complete and the file is not written successfully.
> An information, which you'll never know with current nginx.
>
> Besides even with sync you don't get 100% of guarantees that the write
>> actually ends (correctly) "on the iron" - coming from the land of ZFS
>> ("lots of cheksuming") people will confirm that there are quite a few parts
>> (like drive cache/firmware, controller cache/firmware) which occasionally
>> lie about state of things.
>>
> This is not relevant here. As somebody in this thread said: this has
> nothing to do with nginx. It's the matter of choosing the right hardware.
>
> p.s. then again nginx is also an opensource project and one can
>> implement/propose whatever changes you need for your application even they
>> don't align with authors (for example I also use nginx's webdav module but
>> I do remove everything related to directory delete (to be more safe) just
>> because of the way the app operates)
>>
> Sure. But this also doesn't really add to this discussion.
>
>>
>>
>> Just my 2 cents ..
>>
>> I'm not sure it worths 2 cents. You clearly don't understand the problem
> here, so I'm not sure why you have to speculate about something which I
> didn't write...
> It's completely useless...
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180305/72a88d20/attachment.html>