From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: zlang@redhat.com, fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/2] fsstress: don't abort when stat(".") returns EIO
Date: Wed, 30 Jul 2025 07:23:24 -0700 [thread overview]
Message-ID: <aIoq3LgL2ODgENFy@infradead.org> (raw)
In-Reply-To: <175381958421.3021194.16249782318690545446.stgit@frogsfrogsfrogs>
On Tue, Jul 29, 2025 at 01:10:50PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> First, start with the premise that fstests is run with a nonzero limit
> on the size of core dumps so that we can capture the state of
> misbehaving fs utilities like fsck and scrub if they crash.
Can you explain what this has to do with core dumping?
I'm just really confused between this patch content and the subject of
this patch and the entire series..
> This is really silly, because basic stat requests for the current
> working directory can be satisfied from the inode cache without a disk
> access. In this narrow situation, EIO only happens when the fs has shut
> down, so just exit the program.
If we think it's silly we can trivially drop the xfs_is_shutdown check
in xfs_vn_getattr. But is it really silly? We've tried to basically
make every file system operation consistently fail on shut down
file systems,
> We really should have a way to query if a filesystem is shut down that
> isn't conflated with (possibly transient) EIO errors. But for now this
> is what we have to do. :(
Well, a new STATX_ flag would work, assuming stat doesn't actually
fail :) Otherwise a new ioctl/fcntl would make sense, especially as
the shutdown concept has spread beyond XFS.
next prev parent reply other threads:[~2025-07-30 14:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 20:08 [PATCHSET 3/3] fstests: integrate with coredump capturing Darrick J. Wong
2025-07-29 20:10 ` [PATCH 1/2] fsstress: don't abort when stat(".") returns EIO Darrick J. Wong
2025-07-30 14:23 ` Christoph Hellwig [this message]
2025-07-30 14:55 ` Darrick J. Wong
2025-07-29 20:11 ` [PATCH 2/2] check: collect core dumps from systemd-coredump Darrick J. Wong
2025-08-02 13:47 ` Zorro Lang
2025-08-12 18:14 ` Darrick J. Wong
2025-08-13 15:18 ` [PATCH v2 " Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2025-10-21 18:39 [PATCHSET 2/2] fstests: integrate with coredump capturing Darrick J. Wong
2025-10-21 18:42 ` [PATCH 1/2] fsstress: don't abort when stat(".") returns EIO Darrick J. Wong
2025-10-22 4:22 ` Christoph Hellwig
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=aIoq3LgL2ODgENFy@infradead.org \
--to=hch@infradead.org \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.com \
/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