fsync()-in webdav PUT

Maxim Dounin mdounin at mdounin.ru
Wed Feb 28 14:08:32 UTC 2018


On Wed, Feb 28, 2018 at 10:30:08AM +0100, Nagy, Attila 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.

The question here is - why you want the file to be on disk, and 
not just in a buffer?  Because you expect the server to die in a 
few seconds without flushing the file to disk?  How probable it 
is, compared to the probability of the disk to die?  A more 
reliable server can make this probability negligible, hence the 

(Also, another question is what "on the disk" meas from physical 
point of view.  In many cases this in fact means "somewhere in the 
disk buffers", and a power outage can easily result in the file 
being not accessible even after fsync().)

> Why doing this in a thread is not a good idea? It would'nt block nginx 
> that way.

Because even in threads, fsync() is likely to cause performance 
degradation.  It might be a better idea to let the OS manage 
buffers instead.

Maxim Dounin

More information about the nginx mailing list