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
