All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.