While it’s not clear why one may need to flush the data on each http operation, I can imagine to what performance degradation that may lead of.
if it’s not a some kind of funny clustering among nodes, I wouldn't care much where actual data is, RAM still should be much faster, than disk I/O. br, Aziz. > On 28 Feb 2018, at 12:30, Nagy, Attila <b...@fsn.hu> wrote: > > On 02/27/2018 02:24 PM, Maxim Dounin wrote: >> >>> Now, that nginx supports running threads, are there plans to convert at >>> least DAV PUTs into it's own thread(pool), so make it possible to do >>> non-blocking (from nginx's event loop PoV) fsync on the uploaded file? >> No, there are no such plans. >> >> (Also, trying to do fsync() might not be the best idea even in >> threads. A reliable server might be a better option.) >> > What do you mean by a reliable server? > I want to make sure when the HTTP operation returns, the file is on the disk, > not just in a buffer waiting for an indefinite amount of time to be flushed. > This is what fsync is for. > > Why doing this in a thread is not a good idea? It would'nt block nginx that > way. > _______________________________________________ > 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
