fsync()-in webdav PUT

Valery Kholodkov valery+nginxen at grid.net.ru
Wed Feb 28 18:53:57 UTC 2018

On 28-02-18 15:08, Maxim Dounin wrote:
>> 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
> suggestion.

I think the point here is that lack of fsync leaves some questions 
unanswered. Adding fsync will simply put all dots above the "i"s.

> (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.

fsync does not cause performance degradation. fsync simply instructs OS 
to ensure consistency of a file. What causes performance degradation is 
expenditure of resources necessary to ensure consistency.


More information about the nginx mailing list