tune2fs -I seems dangerous

As a small experiment...

dd if=/dev/zero of=fsfile bs=1M count=16 mkfs.ext4 -F -I 128 fsfile
mkdir -p mnt
mount -o loop fsfile mnt
for I in seq 1 4096; do echo $I > mnt/file.$I; done umount mnt
tune2fs -I 256 fsfile
e2fsck -fy fsfile

... this yields 10031 lines of fsck output, and results in about 38% of the files that were on the filesystem going missing.

I don't have the strong sense that tune2fs -I has been shaken out at all; should it be shipping as a useable option?

Thanks,
-Eric

I have had a similar experience converting from 128 to 256 bytes inodes. After a while, tune2fs -I would simply stop doing IO and using a lot of CPU with a few IO bursts every half-hour or so. This is on a recent/fast x86-64 computer. I had to cancel the thing after leaving it running for over 24 hours.

Maybe add a --accept-consequences-of-shooting-myself-in-the-foot flag ?

Cheers,
Jonathan

Looks like the problem is that tune2fs -I was only tested on ext3 filesystem. It blows up rather spectacularly on filesystems with the flex_bg option, and it's apparently not updating the checksums if the uninit_bg option is specified.

It needs some TLC, that's for certain. Move of the code was copied from resize2fs, so it's pretty paranoid about error checking and so on. The major problems from when the code was adapted for use in expanding the inode table, and the algorithm that tries to do that work.

The major problem is seems to be that it's not double checking to make sure that all of the blocks that it needs to move in order to expand the inode table are in fact moveable. Specifically, the code is not checking and will blindly assume success when in fact things are *not* successful under the following conditions:

1) Flex_bg is enabled, and there is an inode table for a subsequent block group immediately following the inode table.

2) There is a block from the bad block inode immediately following the inode table (which is really bad). Tune2fs -I will not notice, relocate the block in the bad block, and then write the inode table onto the bad block, possibly causing the loss of up to 16 inodes per bad block immediately following the inode table.

3) The filesystem is formatted for RAID so there is stride setting which causes the block or inode bitmap to be located immediately following the inode. This will be caught be e2fsck, if the user is paranoid enough to run e2fsck immediately after tune2fs -I.

I think is fair, though, to say that tune2fs -I code was written by someone who wasn't sufficiently paranoid to think through all of the failure cases. There is in fact a FIXME!! comment for case #2, but at the very least what should have happend is that the move_block should keep track of how many blocks were moved, and if it wasn't equal to needed blocks, it should have signalled an error because it would have indicated either a programming bug or a hardware bug or a filesystem corruption bug. Either way, it shouldn't move forward because there is the risk that users' files might get destroyed.

- Ted

The speed problems have been reported and mostly addressed in the e2fsprogs git repository. There's one more patch that should completely solve the tune2fs -I performance problem, but I haven't had time to audit the patch just yet. It is on my to do list.

- Ted

So for kicks, when I try ext3:

mkfs.ext3 -F -I 128 -N 16384 fsfile
mount -o loop fsfile mnt
for I in seq 1 16384; do echo $I > mnt/file.$I; done umount mnt
tune2fs -I 256 fsfile

tune2fs 1.41.3 (12-Oct-2008)
Error in resizing the inode size.
Run e2undo to undo the file system changes.

e2undo
Usage: e2undo <transaction file> <filesystem>

it seems to me that a) it'd be nice to know what the error was (likely no room for the larger inodes?) and maybe not even begin if you know you'll hit an error due to free space, and b) maybe e2undo (or the previous command) should give you a hint about where the e2undo transaction file is?

It's no my intent to pick on anyone who wrote the code, but it seems like maybe this should be disabled in the next release unless these issues get ironed out...

Thanks,
-Eric