From: Jan Kara <jack@suse.cz> To: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>, Cesar Eduardo Barros <cesarb@cesarb.net>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, Jens Axboe <jaxboe@fusionio.com>, linux-btrfs@vger.kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>, linux-fsdevel@vger.kernel.org, stable@kernel.org, Jens Axboe <axboe@kernel.dk>, Micha?? Piotrowski <mkkp4x4@gmail.com>, Chuck Ebbert <cebbert@redhat.com>, kernel@lists.fedoraproject.org, linux-mtd@lists.infradead.org, David Woodhouse <dwmw2@infradead.org> Subject: Re: Dirtiable inode bdi default != sb bdi btrfs Date: Thu, 30 Sep 2010 01:38:07 +0200 [thread overview] Message-ID: <20100929233806.GB12707@quack.suse.cz> (raw) In-Reply-To: <20100929141006.GB7439@lst.de> On Wed 29-09-10 16:10:06, Christoph Hellwig wrote: > On Wed, Sep 29, 2010 at 02:18:08PM +0200, Jan Kara wrote: > > On Wed 29-09-10 10:19:36, Christoph Hellwig wrote: > > > --- > > > From: Christoph Hellwig <hch@lst.de> > > > Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes > > > > > ... > > > 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. > > Another exception I know about is mtd_inodefs filesystem > > (drivers/mtd/mtdchar.c). > > No, it's not. MTD only has three different backing_dev_info instances > which have different flags in the mapping-relevant portion of the > backing_dev. In the end I agree I was probably wrong but it's not that simple ;) > > So at least here you'd need also add a similar exception for > > "mtd_inodefs". > > No. For one thing we don't need any exception for correctnes alone - > even the block device variant would work fine with the default case. Here I don't agree. If you don't have some kind of exception, sb->s_bdi for both "block" and "mtd_inodefs" filesystems points to noop_backing_dev_info and you get no writeback for that one. So it isn't just a performance issue but also a correctness one. Regarding mtd_inodefs I now looked in more detail what MTD actually does and it seems to me that MTD device inodes do not seem to carry any cached state that flusher threads could write back. So returning noop_backing_dev_info might be the right thing for them after all... (added David Woodhouse and MTD list to CC so that they can shout if it's not the case). Coming to this conclusion, I'm happy with your patch going in as is... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz> To: Christoph Hellwig <hch@lst.de> Cc: Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>, kernel@lists.fedoraproject.org, Jens Axboe <jaxboe@fusionio.com>, linux-kernel@vger.kernel.org, Micha?? Piotrowski <mkkp4x4@gmail.com>, linux-mtd@lists.infradead.org, Chris Mason <chris.mason@oracle.com>, Chuck Ebbert <cebbert@redhat.com>, linux-fsdevel@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>, linux-btrfs@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>, stable@kernel.org, Cesar Eduardo Barros <cesarb@cesarb.net>, Alexander Viro <viro@zeniv.linux.org.uk> Subject: Re: Dirtiable inode bdi default != sb bdi btrfs Date: Thu, 30 Sep 2010 01:38:07 +0200 [thread overview] Message-ID: <20100929233806.GB12707@quack.suse.cz> (raw) In-Reply-To: <20100929141006.GB7439@lst.de> On Wed 29-09-10 16:10:06, Christoph Hellwig wrote: > On Wed, Sep 29, 2010 at 02:18:08PM +0200, Jan Kara wrote: > > On Wed 29-09-10 10:19:36, Christoph Hellwig wrote: > > > --- > > > From: Christoph Hellwig <hch@lst.de> > > > Subject: [PATCH] writeback: always use sb->s_bdi for writeback purposes > > > > > ... > > > 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. > > Another exception I know about is mtd_inodefs filesystem > > (drivers/mtd/mtdchar.c). > > No, it's not. MTD only has three different backing_dev_info instances > which have different flags in the mapping-relevant portion of the > backing_dev. In the end I agree I was probably wrong but it's not that simple ;) > > So at least here you'd need also add a similar exception for > > "mtd_inodefs". > > No. For one thing we don't need any exception for correctnes alone - > even the block device variant would work fine with the default case. Here I don't agree. If you don't have some kind of exception, sb->s_bdi for both "block" and "mtd_inodefs" filesystems points to noop_backing_dev_info and you get no writeback for that one. So it isn't just a performance issue but also a correctness one. Regarding mtd_inodefs I now looked in more detail what MTD actually does and it seems to me that MTD device inodes do not seem to carry any cached state that flusher threads could write back. So returning noop_backing_dev_info might be the right thing for them after all... (added David Woodhouse and MTD list to CC so that they can shout if it's not the case). Coming to this conclusion, I'm happy with your patch going in as is... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR
next prev parent reply other threads:[~2010-09-29 23:38 UTC|newest] Thread overview: 30+ 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-27 23:51 ` Jan Kara 2010-09-27 23:51 ` Jan Kara 2010-09-28 7:05 ` Artem Bityutskiy 2010-09-28 7:05 ` Artem Bityutskiy 2010-09-29 13:00 ` Jan Kara 2010-09-29 13:40 ` Artem Bityutskiy 2010-09-29 13:40 ` Artem Bityutskiy 2010-09-29 13:40 ` Artem Bityutskiy 2010-09-29 8:19 ` Christoph Hellwig 2010-09-29 8:19 ` Christoph Hellwig 2010-09-29 8:19 ` Christoph Hellwig 2010-09-29 12:18 ` Jan Kara 2010-09-29 12:18 ` Jan Kara 2010-09-29 14:10 ` Christoph Hellwig 2010-09-29 23:38 ` Jan Kara [this message] 2010-09-29 23:38 ` Jan Kara 2010-09-30 0:06 ` Christoph Hellwig 2010-09-30 0:06 ` Christoph Hellwig 2010-09-27 23:55 ` Cesar Eduardo Barros 2010-09-29 13:01 ` Jan Kara 2010-09-29 13:01 ` Jan Kara
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=20100929233806.GB12707@quack.suse.cz \ --to=jack@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=axboe@kernel.dk \ --cc=cebbert@redhat.com \ --cc=cesarb@cesarb.net \ --cc=chris.mason@oracle.com \ --cc=dwmw2@infradead.org \ --cc=hch@lst.de \ --cc=jaxboe@fusionio.com \ --cc=kernel@lists.fedoraproject.org \ --cc=linux-btrfs@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=mkkp4x4@gmail.com \ --cc=stable@kernel.org \ --cc=viro@zeniv.linux.org.uk \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.