‐‐‐‐‐‐‐ 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. 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
