Hello, Ted, Thanks indeed for the clarification, it is clear now. OK, if using a loopback mounted image on a disk, underlying file system full then the block device will have I/O error. This loopback mount belongs to a third party common config. I'll fallocate lower disk space to not exhaust disk as a work around firstly. Thanks again for the help:) Best regards, Jianyue Wu On Mon, Jul 14, 2025 at 9:09 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > 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
