linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH, RFC 2/2] ext4: Convert callers of ext4_get_blocks() to use ext4_map_blocks()
Date: Wed, 5 May 2010 14:38:41 -0400	[thread overview]
Message-ID: <20100505183841.GA18762@thunk.org> (raw)
In-Reply-To: <878w80htis.fsf@linux.vnet.ibm.com>

On Tue, May 04, 2010 at 03:34:59PM +0530, Aneesh Kumar K. V wrote:
> > +	ret = ext4_map_blocks(NULL, inode, &map, 0);
> > +	if (ret < 0)
> > +		return ret;
> > +	if (ret == 0) {
> > +		if (!buffer_delay(bh)) {
> 
> bh flags are not set here. This check should be based on map.m_flags.

Actually, I looked more closely at this again today.
ext4_get_blocks() never messed with BH_DELAY, so this flag would only
be set or not set if it was originally set in the buffer_head before
it had been passed into ext4_get_blocks().

BTW, this is one of the reasons why I really hated the old system.  It
was never clear which flags were set by whom, and whether the flags
that had been in the struct bh before it had been passed into
ext4_get_blocks() was random stack garbage, or whether it had meaning,
etc.

I'm still not sure we have it all right, but it's clearly better to
use !buffer_delay(bh), since the buffer_delay flag is one that had
been never touched by ext4_get_blocks().

					- Ted

      parent reply	other threads:[~2010-05-05 18:38 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-03 22:51 [PATCH, RFC 1/2] ext4: Add new abstraction ext4_map_blocks() underneath ext4_get_blocks() Theodore Ts'o
2010-05-03 22:51 ` [PATCH, RFC 2/2] ext4: Convert callers of ext4_get_blocks() to use ext4_map_blocks() Theodore Ts'o
2010-05-04 10:04   ` Aneesh Kumar K. V
2010-05-04 15:42     ` tytso
2010-05-05 18:38     ` tytso [this message]

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=20100505183841.GA18762@thunk.org \
    --to=tytso@mit.edu \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linux-ext4@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;
as well as URLs for NNTP newsgroup(s).