Bug#990243:
Hello Kevin, * Kevin Price [210625 17:45]: > fixed 990243 2.36.1-7 > thanks > > IDK. I'd need to set up a bullseye machine iot test that. > > Done. No, bullseye's utils-linux behaves correctly. Thanks for following up and testing this on bullseye. Chris
Bug#990243:
fixed 990243 2.36.1-7 thanks Dear Chris, Am 25.06.21 um 16:34 schrieb Kevin Price: >> Can the effect still be seen with Linux and util-linux from >> bullseye? > > IDK. I'd need to set up a bullseye machine iot test that. Done. No, bullseye's utils-linux behaves correctly. Filesystem: ext4, block size = 4096 Kernel: linux-image-5.10.0-7-amd64 version 5.10.40-1 Package: util-linux version 2.36.1-7 #BEGIN_TRANSCRIPT $ dd if=/dev/zero bs=1 count=1 of=1-zero-byte 1+0 records in 1+0 records out 1 byte copied, 0.00124056 s, 0.8 kB/s $ du 1-zero-byte 4 1-zero-byte $ fallocate -vd 1-zero-byte 1-zero-byte: 1 B (1 bytes) converted to sparse holes. $ du 1-zero-byte 0 1-zero-byte #END_TRANSCRIPT However the exact same procedure fails to unallocate the block in buster's util-linux version 2.33.1-0.1 . I've found the upstream fix: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?h=stable/v2.36=ed423e56ec43e6cdd5a8475e698f693b56512a63 Best Kevin
Bug#990243:
Dear Chris!
Am 25.06.21 um 15:20 schrieb Chris Hofstaedtler:
> * Kevin Price [210625 11:00]:
>> fallocate -d seems to attempt to unallocate that last block if it
>> contains only zeros, and it even updates the file's mtime. The
>> unallocation is reported, but doesn't effectively happen.
>
> Did you verify this is a bug in fallocate and not a bug or
> side-effect of the kernel-side implementation, possibly in the used
> filesystem?
I'm rather convinced the culprit is fallocate from util-linux, because
using the same kernel and filesystem:
1. With coreutils (dd, truncate) I'm able to create sparse files with
zero blocks and sizes other than multiples of ${block size}.
2. With coreutils (truncate) I'm able to truncate the last block of
zeros and re-add it, becoming an unallocated block. That's how I
successfully sparsified the last block (containing 2048 zeros) of the
debian iso, btw.
Is that convincing, or do you request any additional verification? Some
strace maybe?
> Can the effect still be seen with Linux and util-linux from
> bullseye?
IDK. I'd need to set up a bullseye machine iot test that.
> BTW, which filesystem are you trying this on?
I'm using ext4 with block size=4096, running on buster's stock
linux-image-4.19.0-17-amd64, version 4.19.194-2.
Best
Kevin
Bug#990243: Info received ("fallocate -vd" reports incorrect result)
Hello Kevin, * Kevin Price [210625 11:00]: > fallocate -d seems to attempt to unallocate that last block if it > contains only zeros, and it even updates the file's mtime. The > unallocation is reported, but doesn't effectively happen. Did you verify this is a bug in fallocate and not a bug or side-effect of the kernel-side implementation, possibly in the used filesystem? Can the effect still be seen with Linux and util-linux from bullseye? BTW, which filesystem are you trying this on? Chris
Bug#990243: Info received ("fallocate -vd" reports incorrect result)
tags 990243 -lfs retitle 990243 fallocate -d fails on last block if < block size thanks Dear maintainer, I took a closer look at this bug. Please note that I'm using ext4 with block size=4096. No need to fetch debian-10.10.0-amd64-DLBD-2.iso iot reproduce this bug. This file's last block happens to be 2048 zero-bytes, triggering this bug. I'm seeing the same behavior with a file that consists of a single zero, or of 4095 zeros. I conclude that it happens whenever the file's last block contains only zeros, but is shorter than block size. fallocate -d seems to attempt to unallocate that last block if it contains only zeros, and it even updates the file's mtime. The unallocation is reported, but doesn't effectively happen. My suggestion is to fix fallocate, enabling it to unallocate the last block even if it is shorter than block size. Best Kevin
Bug#990243: "fallocate -vd" reports incorrect result
Dear maintainer, this is what I meant to write: When I try to sparsify a certain, already sparsified file using "fallocate -vd", it reproducibly reports to have freed up 2 KiB, which it hasn't. The file in question is: Name: debian-10.10.0-amd64-DLBD-2.iso Size: 23552321536 MD5: 3cfa82ba8faab8f3e11b108f23a274f3 Transcript: $ du debian-10.10.0-amd64-DLBD-2.iso 23000320debian-10.10.0-amd64-DLBD-2.iso $ fallocate -vd debian-10.10.0-amd64-DLBD-2.iso debian-10.10.0-amd64-DLBD-2.iso: 330 KiB (337920 bytes) converted to sparse holes. $ du debian-10.10.0-amd64-DLBD-2.iso 2292debian-10.10.0-amd64-DLBD-2.iso $ fallocate -vd debian-10.10.0-amd64-DLBD-2.iso debian-10.10.0-amd64-DLBD-2.iso: 2 KiB (2048 bytes) converted to sparse holes. $ du debian-10.10.0-amd64-DLBD-2.iso 2292debian-10.10.0-amd64-DLBD-2.iso Best regards Kevin
Bug#990243: "fallocate -d" reports incorrect result
Package: util-linux Version: 2.33.1-0.1 Severity: minor Tags: lfs "fallocate -d" reports incorrect result -- System Information: Debian Release: 10.10 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.33.1-0.1 ii libaudit1 1:2.8.4-3 ii libblkid1 2.33.1-0.1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libmount1 2.33.1-0.1 ii libpam0g 1.3.1-5 ii libselinux12.8-1+b1 ii libsmartcols1 2.33.1-0.1 ii libsystemd0241-7~deb10u7 ii libtinfo6 6.1+20181013-2+deb10u2 ii libudev1 241-7~deb10u7 ii libuuid1 2.33.1-0.1 ii login 1:4.5-1.1 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 pn util-linux-locales -- no debconf information
