On Thu, Feb 13, 2014 at 09:53:23AM -0500, Jon Bernard wrote: > The image should be available here: > > http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2 Thanks for the image. I've been able to reproduce the problem, and it's caused by the fact that the inode table is so large that it's overflowing into a subsequent block group, and the resize code isn't handling this. Fixing this may be a bit tricky, since the flex_bg online resize code is a big ugly at the moment, and needs some clean up so this can be fixed properly. Until that can be done --- one question: was there a deliberate reason why the file system was created with parameters which allocate 32,752 inodes per block group? That means that a bit over 8 megabytes of inode table are being reserved for every 128 megabyte (32768 4k blocks) block group, and that you have more inodes reserved than could be used if the average file size is 4k or less. In fact, the only way you could run out of inodes is if you had huge numbers of devices, sockets, small symlinks, or zero-length files in your file system. This seems to be a bit of a waste of space, in all liklihood. Don't get me wrong; we should be able to handle this case correctly, and not trigger a BUG_ON, but this is why most people aren't seeing this particular fault --- it requires a far greater number of inodes than mke2fs would ever create by default, or that most system administrators would try to deliberately specify, when creating the file system. I'll look and see what's the best way to fix up fs/ext4/resize.c in the kernel. Regards, - 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
