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.

val
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx