This can be caused by tune2fs -O flex_bg. And clearing flex_bg on such
partitions is harmless.
Signed-off-by: Peng Tao <[email protected]>
---
misc/tune2fs.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/misc/tune2fs.c b/misc/tune2fs.c
index 887a702..f7373af 100644
--- a/misc/tune2fs.c
+++ b/misc/tune2fs.c
@@ -407,7 +407,8 @@ static void update_feature_set(ext2_filsys fs, char *features)
uuid_generate((unsigned char *) sb->s_hash_seed);
}
- if (FEATURE_OFF(E2P_FEATURE_INCOMPAT, EXT4_FEATURE_INCOMPAT_FLEX_BG)) {
+ if (FEATURE_OFF(E2P_FEATURE_INCOMPAT, EXT4_FEATURE_INCOMPAT_FLEX_BG) &&
+ sb->s_log_groups_per_flex) {
if (ext2fs_check_desc(fs)) {
fputs(_("Clearing the flex_bg flag would "
"cause the the filesystem to be\n"
--
1.6.1.3
On Mon, Mar 02, 2009 at 04:28:44PM +0800, Peng Tao wrote:
> This can be caused by tune2fs -O flex_bg. And clearing flex_bg on such
> partitions is harmless.
It's actually not necessarily harmless; e2fsck could have already
assigned new bitmap and inode tables outside of the block group. If
you want to enable this, you need to actually check to make sure all
of the block/inode bitmap blocks and inode tables are within their own
block group before allowing flex_bg to be cleared.
- Ted
On Mon, Mar 2, 2009 at 8:39 PM, Theodore Tso <[email protected]> wrote:
> On Mon, Mar 02, 2009 at 04:28:44PM +0800, Peng Tao wrote:
>> This can be caused by tune2fs -O flex_bg. And clearing flex_bg on such
>> partitions is harmless.
>
> It's actually not necessarily harmless; e2fsck could have already
> assigned new bitmap and inode tables outside of the block group. If
> you want to enable this, you need to actually check to make sure all
> of the block/inode bitmap blocks and inode tables are within their own
> block group before allowing flex_bg to be cleared.
>
> - Ted
>
Thanks for the explanation. I will send a updated patch soon.
--
Cheers,
Bergwolf
................
Jean-Luc Godard - "To be or not to be. That's not really a question."
On Mon, Mar 2, 2009 at 8:39 PM, Theodore Tso <[email protected]> wrote:
> On Mon, Mar 02, 2009 at 04:28:44PM +0800, Peng Tao wrote:
>> This can be caused by tune2fs -O flex_bg. And clearing flex_bg on such
>> partitions is harmless.
>
> It's actually not necessarily harmless; e2fsck could have already
> assigned new bitmap and inode tables outside of the block group. If
> you want to enable this, you need to actually check to make sure all
> of the block/inode bitmap blocks and inode tables are within their own
> block group before allowing flex_bg to be cleared.
>
> - Ted
>
Hi, Ted
Further looking into the code, I realized that tune2fs -O^flex_bg is
already supported if it doesn't break file system consistency. So
please ignore this patch.
I will send you a new patch for enabling tune2fs -I dealing with the
similar scenario.
Cheers,
Bergwolf