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.
Signed-off-by: Jan Kara <[email protected]>
---
fs/ext2/dir.c | 2 +-
fs/ext2/ext2.h | 1 +
fs/ext2/file.c | 21 +++++++++++++++++++--
3 files changed, 21 insertions(+), 3 deletions(-)
Guys, what do you think about the patch below? We carried something similar
in SUSE kernels for quite some time (the original patch was by Chris Mason) -
I've just now got to porting it to current kernel. If nobody objects, I'd
merge the patch...
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 6cde970..545eb42 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -721,5 +721,5 @@ const struct file_operations ext2_dir_operations = {
#ifdef CONFIG_COMPAT
.compat_ioctl = ext2_compat_ioctl,
#endif
- .fsync = simple_fsync,
+ .fsync = ext2_fsync,
};
diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h
index 9a8a8e2..aff22e0 100644
--- a/fs/ext2/ext2.h
+++ b/fs/ext2/ext2.h
@@ -155,6 +155,7 @@ extern void ext2_write_super (struct super_block *);
extern const struct file_operations ext2_dir_operations;
/* file.c */
+extern int ext2_fsync(struct file *file, struct dentry *dentry, int datasync);
extern const struct inode_operations ext2_file_inode_operations;
extern const struct file_operations ext2_file_operations;
extern const struct file_operations ext2_xip_file_operations;
diff --git a/fs/ext2/file.c b/fs/ext2/file.c
index a2f3afd..586e358 100644
--- a/fs/ext2/file.c
+++ b/fs/ext2/file.c
@@ -19,6 +19,7 @@
*/
#include <linux/time.h>
+#include <linux/pagemap.h>
#include "ext2.h"
#include "xattr.h"
#include "acl.h"
@@ -38,6 +39,22 @@ static int ext2_release_file (struct inode * inode, struct file * filp)
return 0;
}
+int ext2_fsync(struct file *file, struct dentry *dentry, int datasync)
+{
+ int ret;
+ struct super_block *sb = dentry->d_inode->i_sb;
+ struct address_space *mapping = sb->s_bdev->bd_inode->i_mapping;
+
+ ret = simple_fsync(file, dentry, datasync);
+ if (ret == -EIO || test_and_clear_bit(AS_EIO, &mapping->flags)) {
+ /* We don't really know where the IO error happened... */
+ ext2_error(sb, __func__,
+ "detected IO error when writing metadata buffers");
+ ret = -EIO;
+ }
+ return ret;
+}
+
/*
* We have mostly NULL's here: the current defaults are ok for
* the ext2 filesystem.
@@ -55,7 +72,7 @@ const struct file_operations ext2_file_operations = {
.mmap = generic_file_mmap,
.open = generic_file_open,
.release = ext2_release_file,
- .fsync = simple_fsync,
+ .fsync = ext2_fsync,
.splice_read = generic_file_splice_read,
.splice_write = generic_file_splice_write,
};
@@ -72,7 +89,7 @@ const struct file_operations ext2_xip_file_operations = {
.mmap = xip_file_mmap,
.open = generic_file_open,
.release = ext2_release_file,
- .fsync = simple_fsync,
+ .fsync = ext2_fsync,
};
#endif
--
1.6.4.2
On Wed, 25 Nov 2009 11:24:53 +0100
Jan Kara <[email protected]> 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?
On 2009-11-25, at 14:48, Andrew Morton wrote:
> On Wed, 25 Nov 2009 11:24:53 +0100
> Jan Kara <[email protected]> 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.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
On Wed 25-11-09 13:48:58, Andrew Morton wrote:
> On Wed, 25 Nov 2009 11:24:53 +0100
> Jan Kara <[email protected]> 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?
Yes, only log message in case errors=continue. OTOH errors=remount-ro is
IMHO more common. But in case we detect metadata IO error (which is what
I've added), calling ext2_error is desirable regardless of what it ends up
doing.
Honza
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 <[email protected]> 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