Testing large ext4 filesystems looks like there are some issues . . . # truncate --size=15t fsfile Ask for a 10T filesystem with just under 2^32 inodes: # /root/git/e2fsprogs/misc/mkfs.ext4 -N 4294967290 -E lazy_itable_init=1 fsfile 10t ... 4292870144 inodes, 2684354560 blocks ... -> first off, 2684354560 4k blocks is not 10 terabytes (?) # mount -o loop fsfile mnt/ # df -h mnt Filesystem Size Used Avail Use% Mounted on /mnt/test2/inodes-test/fsfile 9.0T 189M 8.5T 1% /mnt/test2/inodes-test/mnt # df -i mnt Filesystem Inodes IUsed IFree IUse% Mounted on /mnt/test2/inodes-test/fsfile 4292870144 11 4292870133 1% /mnt/test2/inodes-test/mnt -> now, we are just under the 2^32 inode limit. If we resize2fs will it try to add more? (nb: older resize2fs did detect and fail here): # /root/git/e2fsprogs/resize/resize2fs /dev/loop0 resize2fs 1.43-WIP (21-Jan-2013) Filesystem at /dev/loop0 is mounted on /mnt/test2/inodes-test/mnt; on-line resizing required old_desc_blocks = 1024, new_desc_blocks = 1536 The filesystem on /dev/loop0 is now 4026531840 blocks long. # ho hum, no fail how many inodes did we get? # df -i mnt/ Filesystem Inodes IUsed IFree IUse% Mounted on /mnt/test2/inodes-test/fsfile 2144337920 -4294967285 6439305205 - /mnt/test2/inodes-test/mnt That's no good. :( Also, it said we got resized to 4026531840 blocks, but: # df -B 4096 mnt Filesystem 4K-blocks Used Available Use% Mounted on /mnt/test2/inodes-test/fsfile 3623642086 35452 3422280042 1% /mnt/test2/inodes-test/mnt df says less. During resize this was logged: [161852.517681] EXT4-fs (loop0): resizing filesystem from 2684354560 to 4026531840 blocks [161862.538761] EXT4-fs (loop0): resized to 2815426560 blocks [161872.536461] EXT4-fs (loop0): resized to 2938306560 blocks [161882.543945] EXT4-fs (loop0): resized to 3058892800 blocks [161892.554596] EXT4-fs (loop0): resized to 3174891520 blocks [161902.553146] EXT4-fs (loop0): resized to 3286958080 blocks [161912.576131] EXT4-fs (loop0): resized to 3395747840 blocks [161922.573065] EXT4-fs (loop0): resized to 3499622400 blocks [161932.580859] EXT4-fs (loop0): resized to 3601858560 blocks [161942.597546] EXT4-fs (loop0): resized to 3700490240 blocks [161952.611555] EXT4-fs (loop0): resized to 3797155840 blocks [161962.633435] EXT4-fs (loop0): resized to 3891527680 blocks [161972.631655] EXT4-fs (loop0): resized to 3983605760 blocks [161977.649150] EXT4-fs (loop0): resized filesystem to 4026531840 so why are we left with 3623642086? As for e2fsck it's a mess: # /root/git/e2fsprogs/e2fsck/e2fsck -fn fsfile | more e2fsck 1.43-WIP (21-Jan-2013) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(2684375040--2684389368) +(2684702720--2684717048) .... ad naseum.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
A lot of resize fixes have gone upstream, it's worth retesting this one I think.
Hi Eric, bug fixed in 3.10-rc2, such commit is already on fedora kernel upstream Commit: 3f8a6411fba ext4: add check for inodes_count overflow in new resize ioctl --Carlos
Feel free to mark the fixed-in field & set CLOSED / CURRENTRELEASE I suppose. Thanks, -Eric