From: Christoph Hellwig <hch@lst.de>
To: Chris Mason <chris.mason@oracle.com>, Jan Kara <jack@suse.cz>,
Cesar Eduardo Barros <cesarb@cesarb.net>,
Andrew Morton <akpm@linux-foundation.org>,
hch@lst.de, linux-kernel@vger.kerne
Subject: Re: Dirtiable inode bdi default != sb bdi btrfs
Date: Wed, 29 Sep 2010 10:19:36 +0200 [thread overview]
Message-ID: <20100929081936.GA23322@lst.de> (raw)
In-Reply-To: <20100927225452.GG4270@think>
Here is the patch that I already proposed a while ago. I've tested
xfstests on btrfs and xfstests to make sure the btrfs issue is fixed,
and I've also tested the original dirtying of device files issue
and I/O operations on block device files to test the special case
in the patch.
---
From: Christoph Hellwig <hch@lst.de>
Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes
We currently use struct backing_dev_info for various different purposes.
Originally it was introduced to describe a backing device which includes
an unplug and congestion function and various bits of readahead information
and VM-relevant flags. We're also using for tracking dirty inodes for
writeback.
To make writeback properly find all inodes we need to only access the
per-filesystem backing_device pointed to by the superblock in ->s_bdi
inside the writeback code, and not the instances pointeded to by
inode->i_mapping->backing_dev which can be overriden by special devices
or might not be set at all by some filesystems.
Long term we should split out the writeback-relevant bits of struct
backing_device_info (which includes more than the current bdi_writeback)
and only point to it from the superblock while leaving the traditional
backing device as a separate structure that can be overriden by devices.
The one exception for now is the block device filesystem which really
wants different writeback contexts for it's different (internal) inodes
to handle the writeout more efficiently. For now we do this with
a hack in fs-writeback.c because we're so late in the cycle, but in
the future I plan to replace this with a superblock method that allows
for multiple writeback contexts per filesystem.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/fs/fs-writeback.c
===================================================================
--- linux-2.6.orig/fs/fs-writeback.c 2010-09-29 16:58:41.750557721 +0900
+++ linux-2.6/fs/fs-writeback.c 2010-09-29 17:11:35.040557719 +0900
@@ -72,22 +72,10 @@ int writeback_in_progress(struct backing
static inline struct backing_dev_info *inode_to_bdi(struct inode *inode)
{
struct super_block *sb = inode->i_sb;
- struct backing_dev_info *bdi = inode->i_mapping->backing_dev_info;
- /*
- * For inodes on standard filesystems, we use superblock's bdi. For
- * inodes on virtual filesystems, we want to use inode mapping's bdi
- * because they can possibly point to something useful (think about
- * block_dev filesystem).
- */
- if (sb->s_bdi && sb->s_bdi != &noop_backing_dev_info) {
- /* Some device inodes could play dirty tricks. Catch them... */
- WARN(bdi != sb->s_bdi && bdi_cap_writeback_dirty(bdi),
- "Dirtiable inode bdi %s != sb bdi %s\n",
- bdi->name, sb->s_bdi->name);
- return sb->s_bdi;
- }
- return bdi;
+ if (strcmp(sb->s_type->name, "bdev") == 0)
+ return inode->i_mapping->backing_dev_info;
+ return sb->s_bdi;
}
static void bdi_queue_work(struct backing_dev_info *bdi,
next prev parent reply other threads:[~2010-09-29 8:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-23 0:54 Dirtiable inode bdi default != sb bdi btrfs Cesar Eduardo Barros
2010-09-23 19:38 ` Andrew Morton
2010-09-23 19:40 ` Chris Mason
2010-09-23 19:40 ` Jens Axboe
2010-09-23 20:53 ` [stable] " Greg KH
2010-09-24 18:39 ` Jens Axboe
2010-09-27 0:15 ` Greg KH
2010-09-27 22:25 ` Jan Kara
2010-09-27 22:54 ` Chris Mason
2010-09-28 7:05 ` Artem Bityutskiy
2010-09-29 13:00 ` Jan Kara
2010-09-29 13:40 ` Artem Bityutskiy
2010-09-29 8:19 ` Christoph Hellwig [this message]
[not found] ` <20100929121808.GB3290@quack.suse.cz>
2010-09-29 14:10 ` Christoph Hellwig
2010-09-29 23:38 ` Jan Kara
2010-09-30 0:06 ` Christoph Hellwig
2010-09-27 23:55 ` Cesar Eduardo Barros
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100929081936.GA23322@lst.de \
--to=hch@lst.de \
--cc=akpm@linux-foundation.org \
--cc=cesarb@cesarb.net \
--cc=chris.mason@oracle.com \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kerne \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).