couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: fsync() vs EINTR
Date Thu, 21 May 2015 20:10:36 GMT

> On 21 May 2015, at 21:40, Alexander Shorin <> wrote:
> I think it worth to cross post to erlang-questions@ ML. Would you?

if we don’t get any further here, sure :) — I just don’t want to make
a fool of myself, should this be a simple answer and I feel more
comfortable in this particular crowd, with the CoC and all :)


> --
> ,,,^..^,,,
> On Thu, May 21, 2015 at 10:23 PM, Jan Lehnardt <> wrote:
>> Hi all,
>> I stumbled across and wondered how
this squares against our use of fsync().
>> A quick glance at
reveals that EINTR is handled in multiple places, but only in read/write/sendfile functions,
but not fsync. I also tried to trace the calling code of efile_fsync() (or efile_fdatasync()),
but I got lost pretty quickly in some dtrace macro indirections, so I don’t know if there
is any retry logic higher up.
>> I’m not experienced enough here to make a call, but does that mean that we have
a possible scenario where EINTR interrupts an fsync call after which a crash (machine or CouchDB)
leaves part of a database not fsynced? Or would the failing fsync bubble up to the corresponding,
say, PUT request handler? How about with delayed_commits=true, is the possible data-loss window
then 2 seconds rather than the documented 1s?
>> Can anyone shed any light on this?
>> Best
>> Jan
>> --

Professional Support for Apache CouchDB:

View raw message