On Wed 25-11-09 16:17:32, Andreas Dilger wrote: > On 2009-11-25, at 14:48, Andrew Morton wrote: > >On Wed, 25 Nov 2009 11:24:53 +0100 > >Jan Kara <jack@xxxxxxx> wrote: > >>When an IO error happens while writing metadata buffers, we should > >>better report it and call ext2_error since the filesystem is probably > >>no longer consistent. Sometimes such IO errors happen while flushing > >>thread does background writeback, the buffer gets later evicted > >>from memory, and thus the only trace of the error remains as > >>AS_EIO bit > >>set in blockdevice's mapping. So we check this bit in ext2_fsync and > >>report the error although we cannot be really sure which buffer we > >>failed to write. > > > >So this doesn't cause significant changes in runtime behaviour unless > >the operator specified errors=remount-ro or errors=panic? > > > Debian, at least, always mounts filesystems with errors=remount-ro. > > I _was_ thinking that this would cause errors for even regular file > data, but since it is the bdev mapping and regular files have their > own mappings any errors on the regular files should appear on a > different mapping (which is eventually returned via simple_fsync()). > > The only errors returned from the bdev mapping should be metadata > errors, and we always want to call ext*_error() for those. Exactly. Since ext2 handles also directories via page cache, even errors in directory blocks will not end up in block device's page cache. Honza -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
