public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Pocas, Jamie" <Jamie.Pocas@emc.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: resize2fs stuck in ext4_group_extend with 100% CPU Utilization With Small Volumes
Date: Wed, 23 Sep 2015 12:59:07 -0400	[thread overview]
Message-ID: <20150923165907.GF3318@thunk.org> (raw)
In-Reply-To: <06724CF51D6BC94E9BEE7A8A8CB82A6740FE22BD23@MX01A.corp.emc.com>

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

  reply	other threads:[~2015-09-23 16:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22 19:12 resize2fs stuck in ext4_group_extend with 100% CPU Utilization With Small Volumes Pocas, Jamie
2015-09-22 19:33 ` Eric Sandeen
2015-09-22 20:28   ` Pocas, Jamie
2015-09-22 23:02     ` Theodore Ts'o
2015-09-23  4:20       ` Pocas, Jamie
2015-09-23 15:14         ` Theodore Ts'o
2015-09-23 16:04           ` Pocas, Jamie
2015-09-23 16:59             ` Theodore Ts'o [this message]
2015-09-23 18:20               ` Pocas, Jamie
2015-09-22 20:20 ` Theodore Ts'o
2015-09-22 21:26   ` Pocas, Jamie
2015-09-22 23:41     ` Eric Sandeen
2015-09-23  3:40       ` Pocas, Jamie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150923165907.GF3318@thunk.org \
    --to=tytso@mit.edu \
    --cc=Jamie.Pocas@emc.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox