public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 1/3] bdi: Use parent filesystem BDI for inodes not capable of writeback
Date: Tue, 27 Jul 2010 19:24:38 +0200	[thread overview]
Message-ID: <20100727172437.GE6820@quack.suse.cz> (raw)
In-Reply-To: <20100727170903.GA9034@infradead.org>

On Tue 27-07-10 13:09:03, Christoph Hellwig wrote:
> > +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;
> 
> When do we ever have a writeback-capable bdi that sits inside another
> filesystem?  I think just always using inode->i_sb->s_bdi is the right
> thing here.
  Always returning inode->i_sb->s_bdi wouldn't be a right thing IMHO.
That would file inode for /dev/sda to BDI list of tmpfs mounted on /dev/
which isn't what you want...

> And btw, having a BDI_CAP_NO_WRITEBACK instead of a BDI_CAP_WRITEBACK
> is rather dumb, we'd better fix it up while we're at it.
  Yes, that seems reasonable. I'm just not sure how many places one has
to change to fix this and how to find them... Maybe grepping for BDI_CAP_
will be enough but I'm not sure.
								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2010-07-27 17:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 17:04 [PATCH 0/3] Fix warnings in __mark_inode_dirty Jan Kara
2010-07-27 17:04 ` [PATCH 1/3] bdi: Use parent filesystem BDI for inodes not capable of writeback Jan Kara
2010-07-27 17:09   ` Christoph Hellwig
2010-07-27 17:24     ` Jan Kara [this message]
2010-07-27 17:27       ` Christoph Hellwig
2010-07-27 18:01         ` Jan Kara
2010-07-27 20:12           ` Christoph Hellwig
2010-07-27 20:21             ` Christoph Hellwig
2010-07-27 20:44               ` Jan Kara
2010-07-27 20:46                 ` Christoph Hellwig
2010-07-29  8:12   ` Christoph Hellwig
2010-07-29 12:17     ` Jan Kara
2010-07-27 17:05 ` [PATCH 2/3] char: Mark /dev/zero and /dev/kmem as " Jan Kara
2010-07-27 17:05 ` [PATCH 3/3] bdi: Initialize noop_backing_dev_info properly Jan Kara
2010-07-27 17:09   ` Christoph Hellwig
2010-07-27 17:17     ` 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=20100727172437.GE6820@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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