Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Cc:     mtk.manpages@gmail.com, 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
To:     NeilBrown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
        Jan Kara <jack@suse.cz>
References: <1598685186-27499-1-git-send-email-milan.opensource@gmail.com>
 <CAKgNAkiTjtdaQxbCYS67+SdqSPaGzJnfLEEMFgcoXjHLDxgemw@mail.gmail.com>
 <20200908112742.GA2956@quack2.suse.cz>
 <e4f5ccb298170357ba16ae2870fde6a90ca2aa81.camel@kernel.org>
 <87k0x2k0wn.fsf@notabene.neil.brown.name>
 <8842543f4c929f7004cf356224230516a7fe2fb7.camel@kernel.org>
 <87sgbhi9sf.fsf@notabene.neil.brown.name>
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Message-ID: <20f8c520-49e2-142b-df75-4980a76f3c38@gmail.com>
Date:   Thu, 17 Sep 2020 09:01:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87sgbhi9sf.fsf@notabene.neil.brown.name>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/17/20 1:25 AM, NeilBrown wrote:
> 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....

That woud be great.

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

I think it's useful, and I'd accept patches that make such
distinctions. Of course, if we said *everything* should get fixed
at the same time, nothing would get fixed :-). So, I think
I'd just take individual patches that made such changes on an
ad hoc basis.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/