From: Eric Van Hensbergen <ericvh@kernel.org>
To: Itaru Kitayama <itaru.kitayama@linux.dev>
Cc: Eric Van Hensbergen <eric.vanhensbergen@linux.dev>,
Dominique Martinet <asmadeus@codewreck.org>,
v9fs@lists.linux.dev, Ryan Roberts <ryan.roberts@arm.com>,
David Hildenbrand <david@redhat.com>
Subject: Re: ftruncate fails
Date: Tue, 16 Apr 2024 19:41:55 -0500 [thread overview]
Message-ID: <CAFkjPT=E8fn+W82c+_mf8V4Ok0bJ5JxZ9S=8We3CgXW64qafaw@mail.gmail.com> (raw)
In-Reply-To: <0B23BE9F-87A1-4434-9191-E5FC71031892@linux.dev>
It's fine as a bug, I'm just making sure it wasn't part of the
regressions of some recent patches. (those were my first priority).
I'll take a look at reproducing and see if there is something we can
do here, I haven't looked at ftruncate/fstatfs and what path they
typically take through the kernel - but we should be able to figure
out how to accommodate the open/unlink idiom but I really need to look
at the in-kernel trace and server trace to understand why you are
getting the EOPNOTSUPP which doesn't make sense to me because we
implement statfs in the client (there is no seperate path that I see
for fstatfs) (so maybe worth double checking FVP actually implemented
that in their server) -- but also need to make sure the fid it grabs
is the open fid and not try for a transient fid (although I think that
would be ENOENT, not EOPNOTSUPP). Similar probably for
v9fs_vfs_setattr_dotl -- both of these are used to grabbing the
transient fids, not open fids -- so I may need a catch for fstatfs and
ftruncate to find an open fid on that file.
Will let you know what I find tomorrow.
-eric
prev parent reply other threads:[~2024-04-17 0:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 1:44 ftruncate fails Itaru Kitayama
2024-04-08 2:01 ` Dominique Martinet
2024-04-08 2:08 ` Itaru Kitayama
2024-04-08 2:22 ` Itaru Kitayama
2024-04-08 4:07 ` Dominique Martinet
2024-04-16 14:16 ` Eric Van Hensbergen
2024-04-12 20:36 ` Itaru Kitayama
2024-04-17 0:20 ` Eric Van Hensbergen
2024-04-17 0:25 ` Itaru Kitayama
2024-04-17 0:41 ` Eric Van Hensbergen [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='CAFkjPT=E8fn+W82c+_mf8V4Ok0bJ5JxZ9S=8We3CgXW64qafaw@mail.gmail.com' \
--to=ericvh@kernel.org \
--cc=asmadeus@codewreck.org \
--cc=david@redhat.com \
--cc=eric.vanhensbergen@linux.dev \
--cc=itaru.kitayama@linux.dev \
--cc=ryan.roberts@arm.com \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).