On Wed, Dec 04, 2013 at 09:09:40PM -0500, Theodore Ts'o wrote: > On Wed, Dec 04, 2013 at 05:22:10PM -0800, Darrick J. Wong wrote: > > Right now, e2fsck and resize2fs take care of (B) on their own. > > > > One of my patches fixes everything else (debugfs, dumpe2fs, fuse2fs, tune2fs) > > to take care of (B) by doing it in the library. I can't think of a scenario > > where it'd be useful to run around with something like this: > > > > # mke2fs -t ext4 /dev/vda -O ^resize_inode,meta_bg > > # dumpe2fs /dev/vda > > <snip> > > Group 1: (Blocks 32768-65535) [INODE_UNINIT, BLOCK_UNINIT] > > Checksum 0xa85c, unused inodes 8192 > > Backup superblock at 32768, Group descriptor at 32769 > > ^^^^^ ^^^^^ > > Block bitmap at 3 (bg #0 + 3), Inode bitmap at 19 (bg #0 + 19) > > Inode table at 546-1057 (bg #0 + 546) > > 32766 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes > > Free blocks: 32768-65535 > > ^^^^^ <------------------ HEY! > > Free inodes: 8193-16384 > > > > <snip> > > # debugfs /dev/vda -R 'testb 32768' > > Block 32768 not in use > > I'm not that concerned about dumpe2fs and debugfs, since that's just a > display issue. What's more important is that lib/ext2fs/alloc.c I disagree that testb returning wrong results is a merely display issue. I wasn't expecting to ffb a block I know is free and have other blocks suddenly "become" in use: debugfs: testb 32768 Block 32768 not in use debugfs: ffb 1 65500 Free blocks found: 65500 debugfs: testb 32768 Block 32768 marked in use debugfs: q ext2fs_write_block_bitmap: Attempt to write to filesystem opened read-only ext2fs_close: Attempt to write to filesystem opened read-only I shouldn't have to make debugfs modify the fs just to have testb return correct results. I don't think this qualifies as "least surprise". Anyway, I'll send the patch along and see what everyone thinks of it. > correctly handles allocations --- see check_block_uninit() and > check_inode_uninit() in lib/ext2fs/alloc.c. We do take care of > initializing the portion of the allocation bitmap. > > This is good, because it means that e2tools will do the right thing > when it writes files to an ext4 file system that has BLOCK_UNINIT set > in a block group. I agree that doing the initialization late is better than not doing it at all, so at least we're surprising and not broken. :) --D -- 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
