On 02-03-18 17:06, Maxim Dounin wrote:
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
Because the files I upload to nginx servers are important to me. Please
step back a little and forget that we are talking about nginx or an HTTP
If file are indeed important to you, you have to keep a second
copy in a different location, or even in multiple different
locations. Trying to do fsync() won't save your data in a lot of
quite realistic scenarios, but certainly will imply performance
(and complexity, from nginx code point of view) costs.
But do you understand that even in a replicated setup the time interval
when data reaches permanent storage might be significantly long and
according to your assumptions is random and unpredictable.
In other words, without fsync() it's not possible to make any judgments
about consistency of your data, consequently it's not possible to
implement a program, that tells if your data is consistent or not.
Don't you think that your arguments are fundamentally flawed because you
insist on probabilistic nature of the problem, while it is actually
By the way, even LevelDB has options for synchronous writes:
and it implements them with fsync()
Bitcoin Core varies these options depending on operation mode (see
src/validation.cpp, src/txdb.cpp, src/dbwrapper.cpp).
Oh, I forgot, Bitcoin it's nonsense...
nginx mailing list