| Message ID | 1235982524-7673-1-git-send-email-bergwolf@gmail.com |
|---|---|
| State | Rejected, archived |
| Headers | show |
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 -- 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
On Mon, Mar 2, 2009 at 8:39 PM, Theodore Tso <tytso@mit.edu> 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.
On Mon, Mar 2, 2009 at 8:39 PM, Theodore Tso <tytso@mit.edu> 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 -- 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
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"
This can be caused by tune2fs -O flex_bg. And clearing flex_bg on such partitions is harmless. Signed-off-by: Peng Tao <bergwolf@gmail.com> --- misc/tune2fs.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)