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 from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
