From: Jan Kara <jack@suse.cz>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Buffer state bits
Date: Thu, 27 Aug 2009 16:32:15 +0200 [thread overview]
Message-ID: <20090827143215.GD14240@duck.novell.com> (raw)
In-Reply-To: <20090827123318.GA19422@skywalker.linux.vnet.ibm.com>
On Thu 27-08-09 18:03:18, Aneesh Kumar K.V wrote:
> >
> > BH_Mapped
> > - Buffer has a physical block backing it stored in b_bdev + b_blocknr. This bit
> > is set by filesystem's get_block() function (or by VFS itself for block device
> > mappings).
> >
> > XXX: Some filesystems set BH_Mapped even for buffers that do no really
> > have the backing block (like buffers for delayed allocation). I think
> > we should get rid of it...
> >
>
> Also we don't want get_block to be called multiple times for the same file offset.
> __block_prepare_write does get_block looking at the BH_Mapped flag. ie one of reason
> delay and unwritten buffer_heads are also marked mapped.
Unwritten buffers should be mapped as they really have the backing block.
So that's fine.
Delayed buffers should not be mapped. We could change the check in
__block_prepare_write to "!buffer_mapped(bh) && !buffer_delay(bh)". But I'd
rather avoid it because what I'd like to do in ext3 is to delay-allocate
mmapped blocks and allocate normally blocks written via write(2). So I want
ext3_get_block() to be called in block_prepare_write() even for delay
buffers.
If ext4 doesn't want to do anything for delay buffers in get_block() called
from block_prepare_write(), it can just return from the beginning of
ext4_get_block() when it finds the buffer is delay...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
prev parent reply other threads:[~2009-08-27 14:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 20:00 Buffer state bits Jan Kara
2009-08-26 21:27 ` Jamie Lokier
2009-08-27 11:14 ` Jan Kara
2009-08-27 12:33 ` Aneesh Kumar K.V
2009-08-27 14:32 ` Jan Kara [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=20090827143215.GD14240@duck.novell.com \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@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).