This needs to stop On Monday, March 5, 2018, Nagy, Attila <b...@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@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx