Theodore Tso wrote: > 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. 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 -- 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
