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 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. - 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
