On Wed, Apr 05 2017, Matthew Wilcox wrote: > 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 ... EDQUOT. Remember EDQUOT. It certainly don't affect the whole filesystem. Even without that, filesystems can easily treat different files differently. We shouldn't assume one-failes-all-fail. NeilBrown
Attachment:
signature.asc
Description: PGP signature
