From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "Frédéric Bohé" <frederic.bohe@bull.net>
Cc: "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH v2] ext4: fix initialization of UNINIT bitmap blocks
Date: Mon, 15 Sep 2008 19:06:04 +0530 [thread overview]
Message-ID: <20080915133604.GA6548@skywalker> (raw)
In-Reply-To: <1221481007.6733.32.camel@frecb007923.frec.bull.fr>
On Mon, Sep 15, 2008 at 02:16:47PM +0200, Frédéric Bohé wrote:
> From: Frederic Bohe <frederic.bohe@bull.net>
>
> Do not rely on buffer head's uptodate flag to initialize
> uninitialized bitmap blocks.
>
> Signed-off-by: Frederic Bohe <frederic.bohe@bull.net>
> ---
> Sorry there was a copy/paste error in the previous mail !
>
> This patch makes sure to initialize uninited bitmap blocks.
> These are two test cases where bugs appear because of uninited blocks :
>
> 1- This test case lead to uninited block bitmap and an error message
> from the mballocator during the second dd.
>
> dd if=/dev/urandom of=/dev/md0 bs=1M count=300
> mkfs.ext4 -t ext4dev /dev/md0 1G
> mount -t ext4dev /dev/md0 /mnt/test
> resize2fs /dev/md0 2G
> dd if=/dev/zero of=/mnt/test/dummy bs=1M count=1500
>
> Note that the first dd is to make sure we have random garbage in the
> uninited blocks. If not, you could miss the issue depending what was in
> those blocks before running mkfs.
>
> 2- This test case lead to uninited inode bitmap blocks, making it
> impossible to use all the inodes of the fs.
>
> dd if=/dev/urandom of=/dev/md0 bs=1M count=20
> mkfs.ext4 -t ext4dev /dev/md0 10M
> mount -t ext4dev /dev/md0 /mnt/test
> resize2fs /dev/md0 20M
> for i in $(seq 1 3800); do touch /mnt/test/file${i} 2>&1; done
>
> balloc.c | 4 +++-
> ialloc.c | 4 +++-
> mballoc.c | 4 +++-
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> Index: linux-2.6.27-rc5+patch_queue/fs/ext4/balloc.c
> ===================================================================
> --- linux-2.6.27-rc5+patch_queue.orig/fs/ext4/balloc.c 2008-09-15 10:59:27.000000000 +0200
> +++ linux-2.6.27-rc5+patch_queue/fs/ext4/balloc.c 2008-09-15 14:03:04.000000000 +0200
> @@ -318,9 +318,11 @@ ext4_read_block_bitmap(struct super_bloc
> block_group, bitmap_blk);
> return NULL;
> }
> - if (bh_uptodate_or_lock(bh))
> + if (buffer_uptodate(bh) &&
> + !(desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)))
> return bh;
>
> + lock_buffer(bh);
> spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group));
> if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
> ext4_init_block_bitmap(sb, bh, block_group, desc);
Why ? I guess resize should mark those buffer_heads as not uptodate so
that we do a reinit of block bitmap again later. The above change will
result in calling ext4_init_block_bitmap everytime we do a
read_block_bitmap on an uninit group
> Index: linux-2.6.27-rc5+patch_queue/fs/ext4/ialloc.c
> ===================================================================
> --- linux-2.6.27-rc5+patch_queue.orig/fs/ext4/ialloc.c 2008-09-15 10:59:27.000000000 +0200
> +++ linux-2.6.27-rc5+patch_queue/fs/ext4/ialloc.c 2008-09-15 11:12:16.000000000 +0200
> @@ -115,9 +115,11 @@ ext4_read_inode_bitmap(struct super_bloc
> block_group, bitmap_blk);
> return NULL;
> }
> - if (bh_uptodate_or_lock(bh))
> + if (buffer_uptodate(bh) &&
> + !(desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)))
> return bh;
>
> + lock_buffer(bh);
> spin_lock(sb_bgl_lock(EXT4_SB(sb), block_group));
> if (desc->bg_flags & cpu_to_le16(EXT4_BG_INODE_UNINIT)) {
> ext4_init_inode_bitmap(sb, bh, block_group, desc);
> Index: linux-2.6.27-rc5+patch_queue/fs/ext4/mballoc.c
> ===================================================================
> --- linux-2.6.27-rc5+patch_queue.orig/fs/ext4/mballoc.c 2008-09-15 10:59:27.000000000 +0200
> +++ linux-2.6.27-rc5+patch_queue/fs/ext4/mballoc.c 2008-09-15 14:02:44.000000000 +0200
> @@ -785,9 +785,11 @@ static int ext4_mb_init_cache(struct pag
> if (bh[i] == NULL)
> goto out;
>
> - if (bh_uptodate_or_lock(bh[i]))
> + if (buffer_uptodate(bh[i]) &&
> + !(desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)))
> continue;
>
> + lock_buffer(bh[i]);
> spin_lock(sb_bgl_lock(EXT4_SB(sb), first_group + i));
> if (desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
> ext4_init_block_bitmap(sb, bh[i],
>
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-09-15 13:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-15 11:41 [PATCH] ext4: fix initialization of UNINIT bitmap blocks Frédéric Bohé
2008-09-15 12:16 ` [PATCH v2] " Frédéric Bohé
2008-09-15 13:36 ` Aneesh Kumar K.V [this message]
2008-09-15 14:30 ` Frédéric Bohé
2008-09-18 13:45 ` Frédéric Bohé
2008-09-21 0:44 ` Theodore Tso
2008-09-22 8:09 ` Frédéric Bohé
2008-09-22 8:47 ` Aneesh Kumar K.V
2008-09-22 9:32 ` Frédéric Bohé
2008-09-23 23:13 ` Andreas Dilger
2008-09-24 12:57 ` Frédéric Bohé
2008-09-24 16:23 ` Theodore Tso
2008-09-25 23:04 ` Andreas Dilger
2008-09-24 12:38 ` Frédéric Bohé
2008-09-26 13:17 ` Frédéric Bohé
2008-09-28 22:49 ` Theodore Tso
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=20080915133604.GA6548@skywalker \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=frederic.bohe@bull.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.