On Saturday, February 16, 2019, Maximilian Lorlacks < maxlor...@protonmail.com> wrote:
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, January 31, 2019 11:31 PM, Alexander Bluhm < > alexander.bl...@gmx.net> wrote: > > > On Thu, Jan 31, 2019 at 04:26:45PM -0500, Ted Unangst wrote: > > > > > Instead, we note that the write failed and mark a flag in the vnode. > Future > > > calls to fsync will then return EIO when this flag is set. We clear > the flag > > > when the vnode is released. > > > > Sounds reasonable. > > > > OK bluhm@ > > People may object to errors being lost when the vnode is released, > as that would lose errors in a scenario like write -> close -> open > -> fsync. I do not claim to know if anyone actually does that in the > wild, however. Sorry for my incomplete comment, but I remember a lengthy discussion in the postgres mailing list about fsync, retries of it, loss of state and such, they were very concerned about openbsd behavior I think... Will try to find that thread ... > > If the above diff is accepted, it may be worth to also add the > following diff to fsync.2 to document the behavior: > > diff --git lib/libc/sys/fsync.2 lib/libc/sys/fsync.2 > index c9831ca09..5ee765986 100644 > --- lib/libc/sys/fsync.2 > +++ lib/libc/sys/fsync.2 > @@ -66,6 +66,19 @@ and > .Fn fdatasync > should be used by programs that require a file to be in a known state, > for example, in building a simple transaction facility. > +.Pp > +If > +.Fn fsync > +or > +.Fn fdatasync > +fails with > +.Er EIO , > +the state of the on-disk data may only have been partially written. > +Future attempts to call these functions will continue failing with > +.Er EIO > +until the all copies of the underlying > +.Fa fd > +have been closed. > .Sh RETURN VALUES > .Rv -std fsync fdatasync > .Sh ERRORS > >
