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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Fri, 10 Nov 2023 07:25:49 +0000
From:   "Bandi, Ravi Kumar" <ravib@...zon.com>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
CC:     "tytso@....edu" <tytso@....edu>
Subject: [bigalloc] ext4 filesystem creation fails with specific sizes

Hi,

I'm seeing this issue with ext4 filesystem creation with cluster
allocation (bigalloc).  Filesystem creation fails if size specified
as block count and if that block count results in the number of
blocks in the last block group is less than the number of overhead
blocks.  This lead to the computation of inodes-per-group to overshoot
the limit causing filesystem creation failure.

Observation is, the number of blocks for the filesystem does not
seem to be adjusted to account for this as is done in plain ext4
filesystem (without bigalloc).  I think we should do the same
under bigalloc configuration as well.

To solve the issue, when filesystem creation fails for a specific
block count, I need to retry the operation with block count rounded
to the block group boundary.

Or, am I'm missing something?

Thanks,
Ravi

E.g.
Failure:
    mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 524292

Round the total block count to the blocks-per-group (131072) boundary:
    # echo $(((524292 & ~0x1ffff)))
    524288
    #
Success:
    mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 524288

Current configuration with ex4 profile:
    [defaults]
            blocksize = 4096
            inode_size = 256
            inode_ratio = 16384
            [...]
    [...]

With this configuration, bigalloc with cluster size 16K, 'Blocks per group' is 131072 and 'Inodes per group' is 32768.
    # mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 524288
    # tune2fs -l /dev/nvme1n1
    [...]
    Blocks per group:         131072
    Inodes per group:         32768
    [...]
    #

Example failure #1:
=-=-=-=-=-==-=-=-=
    # mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 524292
    mke2fs 1.47.0 (5-Feb-2023)
    /dev/nvme1n1: Cannot create filesystem with requested number of inodes while setting up superblock
    #

    In this case, the last block group has 4 blocks, but the overhead
    is 1641 blocks.  The inodes-per-group is computed to 32769 (1 more
    than the limit based on the inode_ratio)

    This does not happen on plain ext4 filesystem (without bigalloc).

Example failure #2:
=-=-=-=-=--=-=-=-=
    # wipefs -a /dev/nvme1n1; mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 2097300
    mke2fs 1.47.0 (5-Feb-2023)
    /dev/nvme1n1: Cannot create filesystem with requested number of inodes while setting up superblock
    #

    In this case, last block group has 148 blocks, but the overhead is
    1930.  The inodes-per-group is computed to 32771 and it fails.
    Round the blocks to block group boundary to succeed.
    # echo $(((2097300 & ~0x1ffff)))
    2097152
    #
    # mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 2097152

Example failure #3:
=-=-=-=-=--=-=-=-=
    # wipefs -a /dev/nvme1n1; mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 16778000
    mke2fs 1.47.0 (5-Feb-2023)
    /dev/nvme1n1: Cannot create filesystem with requested number of inodes while setting up superblock
    #

    Here, last block group has 784 blocks, overhead is 2035 and
    inodes-per-group is computed to be 32770 and fails.
    Round the block count to successfully create the filesystem.
    # echo $(((16778000 & ~0x1ffff)))
    16777216
    #
    # mke2fs -m 1 -t ext4 -O bigalloc -C 16384 -b 4096 /dev/nvme1n1 16777216

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ