linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Dunlop <chris@onthe.net.au>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: linux-xfs@vger.kernel.org
Subject: Re: XFS fallocate implementation incorrectly reports ENOSPC
Date: Fri, 27 Aug 2021 12:55:39 +1000	[thread overview]
Message-ID: <20210827025539.GA3583175@onthe.net.au> (raw)
In-Reply-To: <20210826205635.GA2453892@onthe.net.au>

On Fri, Aug 27, 2021 at 06:56:35AM +1000, Chris Dunlop wrote:
> On Thu, Aug 26, 2021 at 10:05:00AM -0500, Eric Sandeen wrote:
>> On 8/25/21 9:06 PM, Chris Dunlop wrote:
>>>
>>> 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.

On further reflection, "filesystems can return ENOSPC at any time" is 
certainly something apps need to be prepared for (and in this case, it's 
doing the right thing, by logging the error and aborting), but it's not 
really a "not a bug" excuse for the filesystem in all circumstances (or 
this one?), is it? E.g. a write(fd, buf, 1) returning ENOSPC on an fresh 
filesystem would be considered a bug, no?

...or maybe your "suboptimal" was entirely tongue in cheek?

>>> 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.

I decided to stop being lazy and look into taking the strace option 
further. I can script looking for the right process as it starts up, and 
with judicious use of "-Z" for failed calls only, and filtering out 
commonly failing syscalls (futex, stat etc.), the output volume is reduced 
to just about nothing. This could be the solution - but it'll probably 
take a week or so for it to fail again and see if I can catch what's going 
on.

Thanks for the inspiration / kick in the pants to get this going.

Strace has grown more options since the last time I looked at the man 
page: "-Z" is fantastic!

Cheers,

Chris

  reply	other threads:[~2021-08-27  2:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-26  2:06 Chris Dunlop
2021-08-26 15:05 ` Eric Sandeen
2021-08-26 20:56   ` Chris Dunlop
2021-08-27  2:55     ` Chris Dunlop [this message]
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=20210827025539.GA3583175@onthe.net.au \
    --to=chris@onthe.net.au \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    --subject='Re: XFS fallocate implementation incorrectly reports ENOSPC' \
    /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

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).