This needs to stop<br><br>On Monday, March 5, 2018, Nagy, Attila <<a href="mailto:bra@fsn.hu">bra@fsn.hu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/05/2018 12:54 PM, Reinis Rozitis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jesus, why? You start the fsync in a thread and you wait for it to be completed<br>
with the HTTP response. Until this happens, the main thread can service other<br>
requests.<br>
Have you ever seen an async program which uses threads to run blocking<br>
operations?<br>
</blockquote>
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).<br>
</blockquote>
The point here is you are completely on the wrong track. I'm not talking about a "background thread".<br>
I was talking about:<br>
1. placing the WHOLE PUT operation into its own thread OR<br>
2. placing just the fsync into a thread (and waiting it to complete with the HTTP response of course)<br>
(or doing something equivalent, which won't block nginx's main thread)<br>
This means the HTTP success or fail response will only be given back AFTER the fsync was successfully completed.<br>
<br>
There is absolutely no problem with a failing fsync. It means the operation couldn't complete and the file is not written successfully.<br>
An information, which you'll never know with current nginx.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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)<br>
</blockquote>
Sure. But this also doesn't really add to this discussion.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Just my 2 cents ..<br>
<br>
</blockquote>
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...<br>
It's completely useless...<br>
______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailm<wbr>an/listinfo/nginx</a><br>
</blockquote>