[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120209224925.GA11737@thunk.org>
Date: Thu, 9 Feb 2012 17:49:25 -0500
From: Ted Ts'o <tytso@....edu>
To: "Darrick J. Wong" <djwong@...ibm.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Collapsing the number of feature flags (was Re: [PATCH v2.3
00/23] ext4: Add metadata checksumming)
On Thu, Feb 09, 2012 at 11:54:44AM -0800, Darrick J. Wong wrote:
>
> Hm... does this make it impossible to add checksums to a fs that doesn't have
> flexbg set? I'm not 100% sure what happens if you enable the flexbg bit on a
> filesystem that wasn't mkfs'd with that turned on. Most of the other flags
> look like they've been mkfs default for years, but I could be wrong.
You can enable flexbg on any file system, and it will work.
Technically the defintion of flexbg is that the block group's metadata
blocks (i.e., allocation bitmaps and inode table) can be located
anywhere on the disk, not just in its own blockgroup. So it just
relaxs checks in the kernel and in e2fsck.
Once you do this there is the natural question of what is the block
group layout that should be used by mke2fs and resize2fs. So we talk
about the flexbg layout, but that's not required by the flexbg feature
flag. For example, for a long time, before we added the new resize
ioctl, an on-line resize would create new block groups using the old
layout (i.e., with the bitmap and inode table blocks in their own
block group).
Try it! You can enable flex_bg on any file system you want, including
an old ext2 file system. That's also a cheap way to force a file
system to be mounted by ext3 or ext4, without making any serious
change to the file system.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists