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/
