On Wed, Apr 05, 2017 at 03:49:52PM -0400, Jeff Layton wrote: > > That only gives us 20 bits of counter, but I think that's enough. > > 2^20 is 1048576, which seems a little small to me. > > We may end up bumping the counter on every failed I/O. How fast can we > generate 1M failed I/Os? :) So there's a one-in-a-million chance of missing a failed I/O ... if we're generating lots of errors, the next time the app calls fsync(), it'll notice the other million times we've hit the problem :-) > Actually...we could put this field in the inode instead of the mapping. > I know we've traditionally tracked this in the mapping, but is that > required here? > > If we put this field in the inode then perhaps we can union it with > something and mitigate the cost of a larger counter...maybe in the > i_pipe union? I don't think S_ISREG inodes use anything in there, do > they? But writeback isn't just done on ISREG inodes, but also on S_ISBLK inodes, which use i_bdev (right?) Another possibility is to move this out of the address_space and into either the super_block or the backing_device_info. Errors don't tend to be constrained to a single file but affect the entire filesystem, or even multiple filesystems if you have a partitioned block device ...
