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@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
