Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, February 16, 2019 7:40 AM, 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.
>
> 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
ping for man diff
(Sorry, Alexander Bluhm, I accidentally forgot to send to list)
