Re: [Lsf-pc] [LSF/MM TOPIC] I/O error handling and fsync()

[Theodore Ts'o <tytso@mit.edu>]

On Wed, Jan 11, 2017 at 10:47:29AM +0100, Jan Kara wrote:
> Well, as Neil pointed out, the problem is that once the data hits page
> cache, we lose the association with a file descriptor. So for example
> background writeback or sync(2) can find the dirty data and try to write
> it, get EIO, and then you have to do something about it because you don't
> know whether fsync(2) is coming or not.

We could solve that by being able to track the number of open file
descriptors in struct inode.  We have i_writecount and i_readcount (if
CONFIG_IMA is defined).  So we can *almost* do this already.  If we
always tracked i_readcount, then we would have the count of all struct
files opened that are writeable or read-only.  So we *can* know
whether or not the page is backed by an inode that has an open file
descriptor.

So the hueristic I'm suggesting is "if i_writecount + i_readcount is
non-zero, then keep the pages".  The pages would be marked with the
error flag, so fsync() can harvest the fact that there was an error,
but afterwards, the pages would be left marked dirty.  After the last
file descriptor is closed, on the next attempt to writeback those
pages, if the I/O error is still occuring, we can make the pages go
away.

					- Ted

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>