Re: kernel bug at fs/ext4/resize.c:409

[Theodore Ts'o <tytso@mit.edu>]

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