linux-ext4 - strange allocator behavior on a 2k block fs, skipping free blocks

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <24fd6030-28f4-b395-4d85-a13be6e2af06@sandeen.net>
Date:   Thu, 16 Apr 2020 14:16:53 -0500
From:   Eric Sandeen <sandeen@...deen.net>
To:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: strange allocator behavior on a 2k block fs, skipping free blocks

This got picked up by xfstests generic/018 on a 2k block filesystem when it
failed to defragment a file into 1 extent as expected.

For some reason, the allocator is skipping over free blocks when it allocates
the donor file.  The attached image shows this behavior - if you do:

# bunzip2 ext4.img.qcow.bz2 
# qemu-img convert -O raw ext4.img.qcow ext4.img
# mkdir -p mnt
# mount -o loop ext4.img mnt/
# fallocate -l 20480 mnt/newfile
# filefrag -v mnt/newfile 
Filesystem type is: ef53
File size of mnt/newfile is 20480 (10 blocks of 2048 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       1:      16962..     16963:      2:             unwritten
   1:        2..       9:      16968..     16975:      8:      16964: unwritten,eof
mnt/newfile: 2 extents found

it allocates 2 extents, even though the blocks in between the extents are free:

# dumpe2fs test.img | grep -w 16964
dumpe2fs 1.42.9 (28-Dec-2013)
  Free blocks: 16964-16967, 16976-17407, 17410-17919, 17922-18431, 18434-18943, 18946-19455, 19457-19967, 19969-32767

I suppose this isn't critical, as defrag is best-effort and the allocator doesn't ever guarantee contiguous allocations, but it still seems a little odd so just thought I'd highlight it.

Thanks,
-Eric

Download attachment "ext4.img.qcow.bz2" of type "application/x-bzip2" (30277 bytes)