From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Curt Wohlgemuth <curtw@google.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: Ensure zeroout blocks have no dirty metadata
Date: Fri, 18 Dec 2009 17:40:08 +0530 [thread overview]
Message-ID: <20091218121008.GE9437@skywalker.linux.vnet.ibm.com> (raw)
In-Reply-To: <20091218114946.GD9437@skywalker.linux.vnet.ibm.com>
On Fri, Dec 18, 2009 at 05:19:46PM +0530, Aneesh Kumar K.V wrote:
> On Thu, Dec 10, 2009 at 09:28:28AM -0800, Curt Wohlgemuth wrote:
> > This fixes a bug in which new blocks returned from an extent created with
> > ext4_ext_zeroout() can have dirty metadata still associated with them.
> >
> > Signed-off-by: Curt Wohlgemuth <curtw@google.com>
A better option would be to do the unmap during fallocate.
commit 87b3121fd9d1223acb08326fc0c9711b0bc3cfeb
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Fri Dec 18 17:38:15 2009 +0530
ext4: unmap the underlying metadata when allocating blocks via fallocate
This become important when we are running with nojournal mode. We
may end up allocating recently freed metablocks for fallocate. We
want to make sure we unmap the old mapping so that when we convert
the fallocated uninitialized extent to initialized extent we don't
have the old mapping around. Leaving the old mapping can cause
file system corruption
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ab31e65..7c0fcae 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1768,6 +1768,20 @@ static inline void set_bitmap_uptodate(struct buffer_head *bh)
set_bit(BH_BITMAP_UPTODATE, &(bh)->b_state);
}
+/*
+ * __unmap_underlying_bh_blocks - just a helper function to unmap
+ * set of blocks described by @bh
+ */
+static inline void __unmap_underlying_bh_blocks(struct inode *inode,
+ struct buffer_head *bh)
+{
+ struct block_device *bdev = inode->i_sb->s_bdev;
+ int blocks, i;
+
+ blocks = bh->b_size >> inode->i_blkbits;
+ for (i = 0; i < blocks; i++)
+ unmap_underlying_metadata(bdev, bh->b_blocknr + i);
+}
#endif /* __KERNEL__ */
#endif /* _EXT4_H */
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 3a7928f..4e646a5 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3508,6 +3508,8 @@ retry:
ret2 = ext4_journal_stop(handle);
break;
}
+ if (buffer_new(&map_bh))
+ __unmap_underlying_bh_blocks(inode, &map_bh);
if ((block + ret) >= (EXT4_BLOCK_ALIGN(offset + len,
blkbits) >> blkbits))
new_size = offset + len;
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 5352db1..7b44737 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2073,22 +2073,6 @@ static void mpage_put_bnr_to_bhs(struct mpage_da_data *mpd, sector_t logical,
}
}
-
-/*
- * __unmap_underlying_blocks - just a helper function to unmap
- * set of blocks described by @bh
- */
-static inline void __unmap_underlying_blocks(struct inode *inode,
- struct buffer_head *bh)
-{
- struct block_device *bdev = inode->i_sb->s_bdev;
- int blocks, i;
-
- blocks = bh->b_size >> inode->i_blkbits;
- for (i = 0; i < blocks; i++)
- unmap_underlying_metadata(bdev, bh->b_blocknr + i);
-}
next prev parent reply other threads:[~2009-12-18 12:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-10 17:28 [PATCH] ext4: Ensure zeroout blocks have no dirty metadata Curt Wohlgemuth
2009-12-10 17:44 ` Eric Sandeen
2009-12-10 18:01 ` Curt Wohlgemuth
2009-12-11 9:09 ` Andreas Dilger
2009-12-11 22:01 ` Curt Wohlgemuth
2009-12-11 23:27 ` Andreas Dilger
2009-12-15 22:33 ` Curt Wohlgemuth
2009-12-18 11:49 ` Aneesh Kumar K.V
2009-12-18 12:10 ` Aneesh Kumar K.V [this message]
2009-12-18 23:11 ` Curt Wohlgemuth
2009-12-29 17:56 ` Curt Wohlgemuth
2009-12-29 18:53 ` tytso
2009-12-29 23:23 ` Curt Wohlgemuth
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=20091218121008.GE9437@skywalker.linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=curtw@google.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