On Wed, Dec 04, 2013 at 05:22:10PM -0800, Darrick J. Wong wrote:
> > 2) The IETF rule of "be conservative in what you send, and liberal in
> > what you accept" applies.
>
> I'm not convinced that we /need/ Akira's patch to clear BLOCK_UNINIT on any
> group containing its own metadata, but I doubt it'd harm anything other than
> make e2fsck slower.
>
> It would certainly be the conservative-send route though.
The place where we are being conserviative what we send is that we
clear BLOCK_UNINIT for block groups that don't have any data blocks,
but which has metadata blocks belonging to *other* block groups,
because there were some kernel implementations in the past that didn't
handle this correctly.
But if you have a block group that has only its metadata, that's
perfectly fine. And that's easy to test; if you create a file system
like this:
touch /tmp/foo.img
mke2fs -t ext2 -O uninit_bg /tmp/foo.img 1800000
... then by definition every single block group has its own metadata,
and if there were problems with block groups that had its own metadata
blocks, we wouldn't be able to set BLOCK_UNINIT on any block group at
all.
It looks like we are currently clearing BLOCK_UNINIT for block groups
that contain superblocks and backup superblocs. To be honest, I don't
remember why we are currently doing this. I *think* the kernel and
all modern e2fsprogs should be able to do the right thing, if we set
BLOCK_UNINIT on all block groups.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
