[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150923165907.GF3318@thunk.org>
Date: Wed, 23 Sep 2015 12:59:07 -0400
From: Theodore Ts'o <tytso@....edu>
To: "Pocas, Jamie" <Jamie.Pocas@....com>
Cc: Eric Sandeen <sandeen@...hat.com>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: resize2fs stuck in ext4_group_extend with 100% CPU Utilization
With Small Volumes
On Wed, Sep 23, 2015 at 12:04:49PM -0400, Pocas, Jamie wrote:
> Interesting. Thanks for the detailed break-down! I don't mind the
> workaround of using 4k "soft" block size on the filesystem, even for
> smaller filesystems. Now that I understand better, I think you were
> on target with your earlier explanation of bd_set_size(). So this
> means it's not an ext4 bug. I think the online resize of loopback
> device (or any other block device driver) should use something like
> the code in check_disk_size_change() instead of bd_set_size(). I
> will have to test this out. Thanks again.
To be clear, the 4k file system block size is an on-disk format thing,
and it will give you better performance (at the cost of increasing
internal fragmentation overhead which can consume more space). It
will cause the soft block size to be set to be 4k when the file system
is mounted, but that's a different thing.
Note that for larger ext4 file systems, or if you are using XFS, the
file system block size will be 4k, so explicitly configuring the
blocksize to 4k isn't anything particularly unusual. It's a change in
the defaults, but I showed you how you can change the defaults by
editing /etc/mke2fs.conf.
Cheers,
- Ted
--
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