From: "Eric Van Hensbergen" <eric.vanhensbergen@linux.dev>
To: "Joakim Sindholt" <opensource@zhasha.com>, v9fs@lists.linux.dev
Cc: "Joakim Sindholt" <opensource@zhasha.com>
Subject: Re: [PATCH v2 2/4] fs/9p: drop inodes immediately on non-.L too
Date: Thu, 28 Mar 2024 15:17:03 +0000 [thread overview]
Message-ID: <a0261e53e93304837656bd8b7d7817b10e299b97@linux.dev> (raw)
In-Reply-To: <145fc52b2452095c44260825670141d0d3b42c7d@linux.dev>
Which server are you testing against? I'm wondering if the underlying problem
might actually be i_nlink being maintained incorrectly by the server which would
lead to inodes lingering since that is the primary way the generic_inode_drop
differentiates. It is possible that we could could add an v9fs_inode_always_drop
in for legacy if the servers weren't reporting i_nlink a compatible fashion
although that might result in never caching legacy 9p2000 (which is probably
what most legacy folks want anyways).
-eric
March 28, 2024 at 10:08 AM, "Eric Van Hensbergen" <eric.vanhensbergen@linux.dev> wrote:
>
> Slowly parsing through these, thanks for the fixes.
>
> This one has a bit of a problem in that we don't have a v9fs specific
>
> drop_inode anymore (either in legacy or .L). The release of the fid should
>
> be handled by v9fs_dir_release in both versions of the protocol.
>
> I had convinced myself we could just use generic_drop_inode because we
>
> decoupled clunking fids from the dentry/inode structures and just handled
>
> them directly in v9fs_dir_release -- so really by recovering the inode
>
> structure every time we were just forcing churn in the inode alloc/dealloc
>
> routines that seemed unnecessary (even in the uncached mode).
>
> Was your concern the performance of the client side lookup of the inode
>
> based on qid or the server side based on fid and can you give me a bit
>
> more information on what you are seeing? Are you not seeing fid clunks
>
> for certain conditions (ie. transient fids, etc.)?
>
> -eric
>
> March 18, 2024 at 6:22 AM, "Joakim Sindholt" <opensource@zhasha.com> wrote:
>
> >
> > Signed-off-by: Joakim Sindholt <opensource@zhasha.com>
> >
> >
> >
> > ---
> >
> >
> >
> > fs/9p/vfs_super.c | 1 +
> >
> >
> >
> > 1 file changed, 1 insertion(+)
> >
> >
> >
> > diff --git a/fs/9p/vfs_super.c b/fs/9p/vfs_super.c
> >
> >
> >
> > index 941f7d0e0bfa..23cc67f29af2 100644
> >
> >
> >
> > --- a/fs/9p/vfs_super.c
> >
> >
> >
> > +++ b/fs/9p/vfs_super.c
> >
> >
> >
> > @@ -310,6 +310,7 @@ static const struct super_operations v9fs_super_ops = {
> >
> >
> >
> > .alloc_inode = v9fs_alloc_inode,
> >
> >
> >
> > .free_inode = v9fs_free_inode,
> >
> >
> >
> > .statfs = simple_statfs,
> >
> >
> >
> > + .drop_inode = v9fs_drop_inode,
> >
> >
> >
> > .evict_inode = v9fs_evict_inode,
> >
> >
> >
> > .show_options = v9fs_show_options,
> >
> >
> >
> > .umount_begin = v9fs_umount_begin,
> >
> >
> >
> > --
> >
> >
> >
> > 2.43.2
> >
>
next prev parent reply other threads:[~2024-03-28 15:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 11:22 Bugfixes for plain 9P2000 Joakim Sindholt
2024-03-18 11:22 ` [PATCH v2 1/4] fs/9p: only translate RWX permissions " Joakim Sindholt
2024-03-18 11:22 ` [PATCH v2 2/4] fs/9p: drop inodes immediately on non-.L too Joakim Sindholt
2024-03-28 15:08 ` Eric Van Hensbergen
2024-03-28 15:17 ` Eric Van Hensbergen [this message]
2024-03-28 15:37 ` Joakim Sindholt
2024-03-28 19:47 ` Eric Van Hensbergen
2024-03-28 20:03 ` Eric Van Hensbergen
2024-03-30 6:47 ` Joakim Sindholt
2024-03-18 11:22 ` [PATCH v2 3/4] fs/9p: translate O_TRUNC into OTRUNC Joakim Sindholt
2024-03-18 11:22 ` [PATCH v2 4/4] fs/9p: fix the cache always being enabled on files with qid flags Joakim Sindholt
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=a0261e53e93304837656bd8b7d7817b10e299b97@linux.dev \
--to=eric.vanhensbergen@linux.dev \
--cc=opensource@zhasha.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