linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Akira Fujita <a-fujita@rs.jp.nec.com>
Cc: Theodore Tso <tytso@mit.edu>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] mke2fs: Fix block bitmaps initalization with -O ^resize_inode
Date: Mon, 25 Nov 2013 17:27:06 -0800	[thread overview]
Message-ID: <20131126012706.GF10269@birch.djwong.org> (raw)
In-Reply-To: <20131123013336.GD10269@birch.djwong.org>

Does the following patch fix your error?  I think I've started to hit it too,
now that I added ^resize_inode,^meta_bg to the mix.

--D

libext2fs: clear BLOCK_UNINIT any time a group has metadata blocks

If ext2fs_reserve_super_and_bgd() is called with the filesystem's
block bitmap, we clear the group's BLOCK_UNINIT flag if the group has
an old-style (pre-metabg) group descriptor block with reserved
descriptor blocks prior to marking the old-style descriptor blocks in
use.

Unfortunately, this is not sufficient -- if the group has no reserved
blocks yet isn't a meta_bg filesystem (^resize_inode,^meta_bg), we
forget to clear the flag, so the filesystem thinks all blocks are
free, which is disastrous.

Therefore, if we know that we're going to mark any of the bitmaps,
make sure that we clear BLOCK_UNINIT.

This is based on an earlier patch by Akira Fujita.

> Steps to reproduce:
> 1. mke2fs -t ext4 -b 4096 -O ^resize_inode device
> 2. e2fsck -b 32768 DEV 
>   <snip>
>   Pass 1: Checking inodes, blocks, and sizes
>   Pass 2: Checking directory structure
>   Pass 3: Checking directory connectivity
>   Pass 4: Checking reference counts
>   Pass 5: Checking group summary information
>   Block bitmap differences:  +(32768--32769) +(98304--98305) +(163840--163841)
>   Fix<y>? 

Reported-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 lib/ext2fs/alloc_sb.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/ext2fs/alloc_sb.c b/lib/ext2fs/alloc_sb.c
index 223ec51..f1898df 100644
--- a/lib/ext2fs/alloc_sb.c
+++ b/lib/ext2fs/alloc_sb.c
@@ -52,6 +52,15 @@ int ext2fs_reserve_super_and_bgd(ext2_filsys fs,
 	ext2fs_super_and_bgd_loc2(fs, group, &super_blk,
 				  &old_desc_blk, &new_desc_blk, &used_blks);
 
+	/*
+	 * If we're marking blocks in the main block bitmap, be sure that we
+	 * clear the group's BLOCK_UNINIT flag if this group has metadata
+	 * blocks allocated.
+	 */
+	if (fs->block_map == bmap &&
+	    (new_desc_blk || old_desc_blk || super_blk || (group == 0)))
+		ext2fs_bg_flags_clear(fs, group, EXT2_BG_BLOCK_UNINIT);
+
 	if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG)
 		old_desc_blocks = fs->super->s_first_meta_bg;
 	else
@@ -65,8 +74,6 @@ int ext2fs_reserve_super_and_bgd(ext2_filsys fs,
 		ext2fs_mark_block_bitmap2(bmap, 0);
 
 	if (old_desc_blk) {
-		if (fs->super->s_reserved_gdt_blocks && fs->block_map == bmap)
-			ext2fs_bg_flags_clear(fs, group, EXT2_BG_BLOCK_UNINIT);
 		num_blocks = old_desc_blocks;
 		if (old_desc_blk + num_blocks >= ext2fs_blocks_count(fs->super))
 			num_blocks = ext2fs_blocks_count(fs->super) -

  reply	other threads:[~2013-11-26  1:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22  7:39 [PATCH] mke2fs: Fix block bitmaps initalization with -O ^resize_inode Akira Fujita
2013-11-22  8:03 ` Akira Fujita
2013-11-23  1:33 ` Darrick J. Wong
2013-11-26  1:27   ` Darrick J. Wong [this message]
2013-11-26  8:10     ` Akira Fujita
2013-11-27  0:55       ` Darrick J. Wong
2013-11-28  8:50         ` Akira Fujita
2013-11-30 20:06           ` Darrick J. Wong
2013-12-04 23:44             ` Theodore Ts'o
2013-12-05  1:22               ` Darrick J. Wong
2013-12-05  2:03                 ` Theodore Ts'o
2013-12-05  5:04                   ` Darrick J. Wong
2013-12-05  2:09                 ` Theodore Ts'o
2013-12-05  5:00                   ` Darrick J. Wong

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=20131126012706.GF10269@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=a-fujita@rs.jp.nec.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).