Re: [PATCH] mke2fs: Fix block bitmaps initalization with -O ^resize_inode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux