fsync()-in webdav PUT
Maxim Dounin
mdounin at mdounin.ru
Sat Mar 3 00:43:02 UTC 2018
Hello!
On Fri, Mar 02, 2018 at 08:47:17PM +0100, Valery Kholodkov wrote:
> 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
> >>> suggestion.
> >> 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
> >> server.
> >
> > 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
> deterministic?
In no particular order:
1. There are no "my assumptions".
2. This is not about consistency, it's about fault tolerance.
Everything is consistent unless a server crash happens.
3. Using fsync() can increase the chance that your data will
survive a server crash / power outage. It doesn't matter in many
other scenarios though, for example, if your disk dies.
4. Trying to insist that reliability is deterministic looks unwise
to me, but it's up to you to insist on anything you want.
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx
mailing list