Re: XFS fallocate implementation incorrectly reports ENOSPC

On Thu, Aug 26, 2021 at 10:05:00AM -0500, Eric Sandeen wrote:

On 8/25/21 9:06 PM, Chris Dunlop wrote:

quoted

fallocate -l 1GB image.img
mkfs.xfs -f image.img
mkdir mnt
mount -o loop ./image.img mnt
fallocate -o 0 -l 700mb mnt/image.img
fallocate -o 0 -l 700mb mnt/image.img

Why does the second fallocate fail with ENOSPC, and is that considered an XFS bug?

Interesting.  Off the top of my head, I assume that xfs is not looking at
current file space usage when deciding how much is needed to satisfy the
fallocate request.  While filesystems can return ENOSPC at any time for
any reason, this does seem a bit suboptimal.

Yes, I would have thought the second fallocate should be a noop.

quoted

Background: I'm chasing a mysterious ENOSPC error on an XFS filesystem 
with way more space than the app should be asking for. There are no 
quotas on the fs. Unfortunately it's a third party app and I can't tell 
what sequence is producing the error, but this fallocate issue is a 
possibility.

Presumably you've tried stracing it and looking for ENOSPC returns from
syscalls?

That would be an obvious approach. Unfortunately it's not that easy. The 
problem is associated with one specific client which is out of my control 
so I can't experiment in a controlled environment. The app runs for 
several hours in multiple phases, each with multiple threads, and the 
problem typically occurs in the early hours of the morning after several 
hours of running, so attaching to the correct instance is fraught, and the 
strace output will be voluminous.

Cheers,

Chris