[resend without accidentally dropping the cc's] On Wed, Dec 04, 2013 at 09:03:40PM -0500, Theodore Ts'o wrote: > 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 Looking at the git history, that chunk of ext2fs_reserve_super_and_bgd() landed there when you were trying to clean up libext2fs, though there's no obvious reason why we need to unset BLOCK_UNINIT there too. Oh well, it can't hurt. > all modern e2fsprogs should be able to do the right thing, if we set > BLOCK_UNINIT on all block groups. Fortunately, they do, and have since the initial ext4dev code in 2006-7. --D > > - 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
