From: NeilBrown <neilb@suse.de>
To: Jeff Layton <jlayton@kernel.org>, Jan Kara <jack@suse.cz>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: milan.opensource@gmail.com, lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] fsync.2: ERRORS: add EIO and ENOSPC
Date: Thu, 17 Sep 2020 09:25:36 +1000 [thread overview]
Message-ID: <87sgbhi9sf.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <8842543f4c929f7004cf356224230516a7fe2fb7.camel@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
On Thu, Sep 10 2020, Jeff Layton wrote:
>
>> Regarding your "NOTES" addition, I don't feel comfortable with the
>> "clean" language. I would prefer something like:
>>
>> When fsync() reports a failure (EIO, ENOSPC, EDQUOT) it must be assumed
>> that any write requests initiated since the previous successful fsync
>> was initiated may have failed, and that any cached data may have been
>> lost. A future fsync() will not attempt to write out the same data
>> again. If recovery is possible and desired, the application must
>> repeat all the writes that may have failed.
>>
>> If the regions of a file that were written to prior to a failed fsync()
>> are read, the content reported may not reflect the stored content, and
>> subsequent reads may revert to the stored content at any time.
>>
>
> Much nicer.
I guess someone should turn it into a patch....
>
> Should we make a distinction between usage and functional classes of
> errors in this? The "usage" errors will probably not result in the pages
> being tossed out, but the functional ones almost certainly will...
Maybe. I think it is a useful distinction, but to be consistent it
would be best to make it in all (section 2) man pages. Maybe not all at
once though. It is really up to Michael if that is a direction he is
interesting in following.
NeilBrown
>
> --
> Jeff Layton <jlayton@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]
next prev parent reply other threads:[~2020-09-16 23:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1598685186-27499-1-git-send-email-milan.opensource@gmail.com>
2020-09-07 7:11 ` [PATCH] fsync.2: ERRORS: add EIO and ENOSPC Michael Kerrisk (man-pages)
2020-09-08 11:27 ` Jan Kara
2020-09-08 16:10 ` Jeff Layton
2020-09-09 22:50 ` NeilBrown
2020-09-08 19:44 ` Jeff Layton
2020-09-09 10:53 ` Michael Kerrisk (man-pages)
2020-09-09 23:04 ` NeilBrown
2020-09-10 17:42 ` Jeff Layton
2020-09-16 23:25 ` NeilBrown [this message]
2020-09-17 7:01 ` Michael Kerrisk (man-pages)
2020-09-09 10:52 ` Michael Kerrisk (man-pages)
2020-09-09 11:21 ` Jan Kara
2020-09-09 11:58 ` Michael Kerrisk (man-pages)
2020-09-09 14:14 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sgbhi9sf.fsf@notabene.neil.brown.name \
--to=neilb@suse.de \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=milan.opensource@gmail.com \
--cc=mtk.manpages@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).