On Tue, 2018-09-04 at 13:42 +0800, 焦晓冬 wrote: > Hi, > > After reading several writeback error handling articles from LWN, I > begin to be upset about writeback error handling. > > Jlayton's patch is simple but wonderful idea towards correct error > reporting. It seems one crucial thing is still here to be fixed. Does > anyone have some idea? > > The crucial thing may be that a read() after a successful open()- > write()-close() may return old data. > That may happen where an async writeback error occurs after close() > and the inode/mapping get evicted before read(). > > That violate POSIX as POSIX requires that a read() that can be proved > to occur after a write() has returned will return the new data. That can happen even before a close(), and it varies by filesystem. Most filesystems just pretend the page is clean after writeback failure. It's quite possible to do: write() kernel attempts to write back page and fails page is marked clean and evicted from the cache read() Now your write is gone and there were no calls between the write and read. The question we still need to answer is this: When we attempt to write back some data from the cache and that fails, what should happen to the dirty pages? Unfortunately, there are no good answers given the write/fsync/read model for I/O. I tend to think that in the long run we may need new interfaces to handle this better. -- Jeff Layton <jlayton@xxxxxxxxxx>
