On Tue, Jul 31, 2012 at 04:40:36PM -0500, Eric Sandeen wrote: > > The problem is that fallocate allocated a large number of blocks, which > > mke2fs then immediately discarded as its first order of business. > > Hm, then why didn't mkfs.ext4 -K solve the problem.... I wasn't able to replicate it with mkfs.ext4 -K on a 3.2 kernel. However, with a 3.2 kernel, if you have a pre-existing file1 created via the fallocate, mke2fs, umount, e2fsck series of commands, the fallocate command will BUG. More interestingly, if you have an extent tree created using a 3.2 kernel, and then mount it on using a 3.5+ext4 patches for 3.6 kernel, it still BUG's. It dies on line 837 of extent.c: len = EXT_LAST_INDEX(curp->p_hdr) - ix + 1; BUG_ON(len < 0); Obviously, it shouldn't do that, and that is a bug which is upstream in the latest 3.6-rc0 kernel. But it only happens on a file system that had tripped over the 3.2 kernel bug first. At the very least, the BUG_ON should be an ext4_error() --- but given that this is a file system that was given clean bill of health by e2fsck, we should handle it in a more graceful way. Of course, it might be a good idea if e2fsck was taught how to clean up non-standard extent trees that have empty extent tree leaf nodes, but nevertheless, the kernel *should* be able to handle non-standard/non-optimal extent tree blocks in a sane fashion. - 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
