[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87hbydkbf2.fsf@devron.myhome.or.jp>
Date: Thu, 18 Jun 2009 20:51:13 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Jan Kara <jack@...e.cz>
Cc: LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, npiggin@...e.de
Subject: Re: [PATCH 07/11] vfs: Unmap underlying metadata of new data buffers only when buffer is mapped
Jan Kara <jack@...e.cz> writes:
> When we do delayed allocation of some buffer, we want to signal to VFS that
> the buffer is new (set buffer_new) so that it properly zeros out everything.
> But we don't have the buffer mapped yet so we cannot really unmap underlying
> metadata in this state. Make VFS avoid doing unmapping of metadata when the
> buffer is not yet mapped.
I may be missing something. However, isn't the delalloc buffer ==
(buffer_mapped() | buffer_delay())? Well, anyway, if buffer is not
buffer_mapped(), e.g. truncate() works properly?
Thanks.
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 80e2630..7eb1710 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1683,8 +1683,9 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> if (buffer_new(bh)) {
> /* blockdev mappings never come here */
> clear_buffer_new(bh);
> - unmap_underlying_metadata(bh->b_bdev,
> - bh->b_blocknr);
> + if (buffer_mapped(bh))
> + unmap_underlying_metadata(bh->b_bdev,
> + bh->b_blocknr);
Is this needed for writepage?
> }
> }
> bh = bh->b_this_page;
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists