linux-ext4 - RE: resize2fs stuck in ext4_group_extend with 100% CPU Utilization With Small Volumes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 23 Sep 2015 14:20:45 -0400
From:	"Pocas, Jamie" <Jamie.Pocas@....com>
To:	"Theodore Ts'o" <tytso@....edu>
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

I understand the tradeoff. Thanks. I tested a change in the driver from calling bd_set_size() to calling check_disk_size_change() and it is in fact working as expected! I can see that the capacity is increased correctly, but the blocksize reported by 'blockdev --getbsz' is still retained as 1024 correctly. Obviously this needs more review and testing, but I think this is a bug with loopback and any other driver that would call bd_set_size() to do online resize. As far as ext is concerned, consider it case-closed. Thanks again for the tips.

-----Original Message-----
From: Theodore Ts'o [mailto:tytso@....edu] 
Sent: Wednesday, September 23, 2015 12:59 PM
To: Pocas, Jamie
Cc: Eric Sandeen; 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