linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Chris Dunlop <chris@onthe.net.au>, linux-xfs@vger.kernel.org
Subject: Re: XFS fallocate implementation incorrectly reports ENOSPC
Date: Thu, 26 Aug 2021 10:05:00 -0500	[thread overview]
Message-ID: <335ae292-cb09-6e6e-9673-68cfae666fc0@sandeen.net> (raw)
In-Reply-To: <20210826020637.GA2402680@onthe.net.au>



On 8/25/21 9:06 PM, Chris Dunlop wrote:
> Hi,
> 
> As reported by Charles Hathaway here (with no resolution):
> 
> XFS fallocate implementation incorrectly reports ENOSPC
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791323
> 
> Given this sequence:
> 
> 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.
  
> Ext4 is happy to do the second fallocate without error.
> 
> Tested on linux-5.10.60
> 
> 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?

-Eric

  reply	other threads:[~2021-08-26 15:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26  2:06 XFS fallocate implementation incorrectly reports ENOSPC Chris Dunlop
2021-08-26 15:05 ` Eric Sandeen [this message]
2021-08-26 20:56   ` Chris Dunlop
2021-08-27  2:55     ` Chris Dunlop
2021-08-27  5:49       ` Dave Chinner
2021-08-27  6:53         ` Chris Dunlop
2021-08-27 22:03           ` Dave Chinner
2021-08-28  0:21             ` Mysterious ENOSPC [was: XFS fallocate implementation incorrectly reports ENOSPC] Chris Dunlop
2021-08-28  3:58               ` Chris Dunlop
2021-08-29 22:04                 ` Dave Chinner
2021-08-30  4:21                   ` Darrick J. Wong
2021-08-30  7:40                     ` Chris Dunlop
2021-08-30  7:37                   ` Mysterious ENOSPC Chris Dunlop
2021-09-02  1:42                     ` Dave Chinner
2021-09-17  6:07                       ` Chris Dunlop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=335ae292-cb09-6e6e-9673-68cfae666fc0@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=chris@onthe.net.au \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).