From: Dominique Martinet <asmadeus@codewreck.org>
To: Kent Overstreet <kent.overstreet@linux.dev>, Tingmao Wang <m@maowtm.org>
Cc: v9fs@lists.linux.dev, netfs@lists.linux.dev,
linux-fsdevel@vger.kernel.org,
David Howells <dhowells@redhat.com>,
Eric Van Hensbergen <ericvh@kernel.org>,
Latchesar Ionkov <lucho@ionkov.net>
Subject: Re: -ENODATA from read syscall on 9p
Date: Sun, 12 Oct 2025 04:40:14 +0900 [thread overview]
Message-ID: <aOqynl8t6_KvUlM0@codewreck.org> (raw)
In-Reply-To: <da9b0573-506a-4ce3-88f3-b1714b32db5f@maowtm.org>
Tingmao Wang wrote on Sat, Oct 11, 2025 at 03:35:00PM +0100:
> Not a 9pfs maintainer here, but I think I have encountered this in the
> past but I didn't think too much of it. Which kernel version are you
> testing on? A while ago I sent a patch to fix some stale metadata
> issue on uncached 9pfs, and one of the symptom was -ENODATA from a read:
> https://lore.kernel.org/all/cover.1743956147.git.m@maowtm.org/
>
> Basically, if some other process has a 9pfs file open, and the file
> shrinks on the server side, the inode's i_size is not updated when another
> process tries to read it, and the result is -ENODATA (instead of reporting
> a normal EOF).
>
> Does this sound like it could be happening in your situation? This patch
> series should land in 6.18, so if this was not reproduced on -next it
> might be worth a try?
It got merged in yesterday
With that said I'm also curious if that's the reason 9p reads stopped
progressing, but even with this patch I think there'd be a window for
files to shrink while the read is happening so netfs needs to return a
short read anyway -- if the file really is being modified under us it's
possible to hit end of file early.
OTOH I don't think that's what's happening here though, as Kent is
likely just running xfstest on its own in a directory...
You says these errors just started happening recently?
How recently are you talking?
I doubt it's been months but the only recent changes I see in this area
would be the netfs i_size updating patches early July.. If it's more
recent than that there's something else I didn't see anything obvious,
having a rough range to look at would be welcome for closer inspection.
--
Dominique Martinet | Asmadeus
prev parent reply other threads:[~2025-10-11 19:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-08 17:54 -ENODATA from read syscall on 9p Kent Overstreet
2025-10-11 14:35 ` Tingmao Wang
2025-10-11 19:40 ` Dominique Martinet [this message]
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=aOqynl8t6_KvUlM0@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=dhowells@redhat.com \
--cc=ericvh@kernel.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=m@maowtm.org \
--cc=netfs@lists.linux.dev \
--cc=v9fs@lists.linux.dev \
/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).