[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6E255D1A-534A-4039-9102-CF8CBE2FBE25@dilger.ca>
Date: Thu, 13 Feb 2014 20:13:33 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: Theodore Ts'o <tytso@....edu>
Cc: Dmitry Monakhov <dmonakhov@...nvz.org>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: kernel bug at fs/ext4/resize.c:409
On Feb 13, 2014, at 14:18, Theodore Ts'o <tytso@....edu> wrote:
> 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.
This is fairly normal for Lustre metadata targets, where the
inodes typically do not have any data blocks. We typically format the
MDT filesystem with an average of 2KB per inode.
> 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.
That said, Lustre also doesn't allow online resize yet (no way to pass
the ioctl() from userspace to the underlying ext4 filesystem), so
we haven't hit this yet.
Cheers, Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists