[PATCH 1/3] bdi: Use parent filesystem BDI for inodes not capable of writeback
in [Kernel]
|
Prev: [PATCH 2/3] char: Mark /dev/zero and /dev/kmem as not capable of writeback
Next: [PATCH 0/3] Fix warnings in __mark_inode_dirty
From: Jan Kara on 27 Jul 2010 13:10 If inode->i_mapping->backing_dev_info is not capable of writeback but the inode gets dirty (because inode itself has changed), use inode lists of a bdi of a filesystem holding the device inode. Forking the flusher thread just to do the writeout of a single inode would be silly and generally bdi needn't be prepared to do any writeback. This is part of fixing a bug https://bugzilla.kernel.org/show_bug.cgi?id=16312. Signed-off-by: Jan Kara <jack(a)suse.cz> --- fs/fs-writeback.c | 17 +++++++++++++++-- 1 files changed, 15 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index d5be169..00865aa 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -28,8 +28,6 @@ #include <linux/buffer_head.h> #include "internal.h" -#define inode_to_bdi(inode) ((inode)->i_mapping->backing_dev_info) - /* * We don't actually have pdflush, but this one is exported though /proc... */ @@ -50,6 +48,21 @@ struct wb_writeback_work { struct completion *done; /* set if the caller waits */ }; +static struct backing_dev_info *inode_to_bdi(struct inode *inode) +{ + struct backing_dev_info *bdi = inode->i_mapping->backing_dev_info; + + /* + * This is a hack but it solves a problem with device inode + * for e.g. /dev/zero getting dirty (via touch or so) and confusing + * writeback code. In such cases we return the "parent" filesystem's + * bdi. + */ + if (bdi_cap_writeback_dirty(bdi)) + return bdi; + return inode->i_sb->s_bdi; +} + /** * writeback_in_progress - determine whether there is writeback in progress * @bdi: the device's backing_dev_info structure. -- 1.6.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |