On Thu, Oct 23, 2008 at 10:44:16AM +0100, steve@xxxxxxxxxxx wrote: > Hi, > > On Thu, Oct 23, 2008 at 09:07:11AM +0200, Nick Piggin wrote: > > On Thu, Oct 23, 2008 at 10:07:15AM +1100, Dave Chinner wrote: > [snip] > > > > > You could do the same thing for metadata read operations. e.g. build > > > a large directory structure, then do read operations on it (readdir, > > > stat, etc) and inject errors into each of those. All filesystems > > > should return the (EIO) error to the application in this case. > > > > > > Those two cases should be pretty generic and deterministic - they > > > both avoid the difficult problem of determining what the response > > > to an I/O error during metadata modifcation should be.... > > > > Good suggestion. > > > > I'll see what I can do. I'm using the fault injection stuff, which I > > don't think can distinguish metadata, so I might just have to work > > out a bio flag or something we can send down to the block layer to > > distinguish. > > > > Thanks, > > Nick > > > > Don't we already have such a flag? I know that its not set in all > the correct places in GFS2 so far, but I've gradually been fixing > them to include BIO_RW_META where appropriate. That should probably work. It seems to be very incomplete (GFS2 being one of the few exceptions). Though adding more support in ext2 and buffer layer should be enough for me to start with, and shouldn't be too hard. > Also it occurs to me that we can use FIEMAP to discover where a > parciular file is and that would then allow us to target error > injection at particular blocks of the file. > > Given that we can cover xattr blocks with FIEMAP too[*], and that at > least with GFS2 and similar filesystems the inode number is the > block number of the inode, the only thing that would be missing, > in terms of locating inode data & metadata would be the indirect blocks, That would be interesting. I'm finding it hard to come up with good ways to trigger a lot of the cases just for single-file case, so I won't need to do anything so advanced yet ;) -- 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
