linux-ext4 - Re: Issue with ext4 filesystem corruption when writing to a file after disk exhaustion

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

Message-ID: <20250714130951.GB41071@mit.edu>
Date: Mon, 14 Jul 2025 09:09:51 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Jiany Wu <wujianyue000@...il.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, yi.zhang@...wei.com, jack@...e.cz,
        linux-ext4@...r.kernel.org
Subject: Re: Issue with ext4 filesystem corruption when writing to a file
 after disk exhaustion

On Mon, Jul 14, 2025 at 12:37:21PM +0800, Jiany Wu wrote:
> Hello, Ted,
> 
> Good day, thanks indeed for the clarification~
> Yes, previously tried to mount a specific ext4 disk-img to /var/log,
> with /dev/loop1 device, and rsyslogd will write to /var/log/syslog.
> When /tmp directory exhaust manually via fallocate, / dir will be also
> occupied as 100%, and rsyslog write errors in /dev/loop1 happen, later
> mount as read-only. Different from the early scenario, but this
> scenario is not easy to reproduce.
> Tried updating the test case, not fallocate all spaces in disk, now
> alloc 95%, everything is normal now, no related error prints anymore.
> It is confirmed errors are caused by disk exhaust.
> I think the main hesitation part is whether fallocate is allowed to
> use the whole disk space.

The fallocate system call is allowed to use the whole space on the
*file system*.  But it doesn't know about how much free space a
thin-provisioned device's underlying storage is available.  If you are
using a loopback mounted image on a disk, if the underlying file
system on the disk fills up then the block device will have I/O errors
--- and then the file system on the loop device will run into
problems, either data loss or metadata corruption.

So this is working as intended.  If you don't want this, either don't
use a loopback mount with a sparse file; either use fallocate when
creating the image file, or don't use a loopback mount.

				- Ted