Linux 9p file system development
 help / color / mirror / Atom feed
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
> >
>

  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