Hi all, I've found a bug in XFS user quota handling in two subsequent fallocate() calls. This bug can be easily reproduced by the following script: # assume empty XFS mounted on /mnt/testxfs with -o usrquota, grpquota FILE="/mnt/testxfs/test.file" USER="testuser" setquota -u $USER $QUOTA $QUOTA 0 0 -a touch $FILE chown $USER:users $FILE fallocate --keep-size -o 0 -l $FILESIZE $FILE fallocate -o 0 -l $FILESIZE $FILE That is, we create an empty file, preallocate requested size while keeping zero file size and then call fallocate again to set the file size. Assume that there's enaugh free quota to fit the requested file size. In this case, both fallocate calls should succeed because the second one just increases the file size but does not change the allocated space. However, I observed that the second fallocate fails with EDQUOT if the free quota is less than _two times_ of the requested file size. I guess that the second fallocate ignores the fact that the space was already preallocated and accounts the requested size for the second time. For example, if QUOTA=2GiB, file size FILESIZE=800 MiB succeeds but FILESIZE=1600 MiB triggers EDQUOT in second fallocate. The same test performed on EXT4 always succeeds. I've found this issue while investigating why Samba (ver. 4.9.5) returns disk full error although there's still enaugh room for the copied file. Indeed, when Samba's "strict allocate" options is turned on Samba uses the above described sequence of two fallocate() syscalls to create a new file. We noticed this behavior on Debian Buster 4.19 kernel and confirmed on stable 5.10.15 vanilla kernel. Best regards, Martin
