Re: [PATCH v2 2/3] 9p: Introduce option for negative dentry cache retention time

[Remi Pommarel <repk@triplefau.lt>]

On Wed, Feb 11, 2026 at 04:58:02PM +0100, Christian Schoenebeck wrote:
> On Wednesday, 21 January 2026 20:56:09 CET Remi Pommarel wrote:
> > Add support for a new mount option in v9fs that allows users to specify
> > the duration for which negative dentries are retained in the cache. The
> > retention time can be set in milliseconds using the ndentrytmo option.
> > 
> > For the same consistency reasons, this option should only be used in
> > exclusive or read-only mount scenarios, aligning with the cache=loose
> > usage.
> > 
> > Signed-off-by: Remi Pommarel <repk@triplefau.lt>
> > ---
> >  fs/9p/v9fs.c | 9 ++++++++-
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
> > index 1da7ab186478..f58a2718e412 100644
> > --- a/fs/9p/v9fs.c
> > +++ b/fs/9p/v9fs.c
> > @@ -39,7 +39,7 @@ enum {
> >  	 * source if we rejected it as EINVAL */
> >  	Opt_source,
> >  	/* Options that take integer arguments */
> > -	Opt_debug, Opt_dfltuid, Opt_dfltgid, Opt_afid,
> > +	Opt_debug, Opt_dfltuid, Opt_dfltgid, Opt_afid, Opt_ndentrytmo,
> >  	/* String options */
> >  	Opt_uname, Opt_remotename, Opt_cache, Opt_cachetag,
> >  	/* Options that take no arguments */
> > @@ -93,6 +93,7 @@ const struct fs_parameter_spec v9fs_param_spec[] = {
> >  	fsparam_string	("access",	Opt_access),
> >  	fsparam_flag	("posixacl",	Opt_posixacl),
> >  	fsparam_u32	("locktimeout",	Opt_locktimeout),
> > +	fsparam_s32	("ndentrytmo",	Opt_ndentrytmo),
> 
> Not better "ndentrytimeout" ?

I just wanted to avoid to re-align all the above, but lazyness should
not prevail over readability :). I will change that thanks.

> 
> My first thought was whether it was really worth introducing a dedicated
> timeout option exactly for negative dentries (instead of a general cache
> timeout option). But on a 2nd thought it actually needs separate handling, as
> negative dentries have the potential to pollute with a ridiculous amount of
> bogus entries.

Agreed.

> 
> Wouldn't it make sense to enable this option with some meaningful value for
> say cache=loose by default? 24 hours maybe?

That is an interesting question, I have seen pretty satisfying (at least
for me) perf results on the different builds I ran, even with a 1 to 2
seconds cache timeout, maybe this would be a good tradeoff for
cache=loose being almost transparent in the eye of the user ? But maybe
this is too specific to the build workflow (that hit the same negative
dentries fast enough) ?

> 
> > 
> >  	/* client options */
> >  	fsparam_u32	("msize",	Opt_msize),
> > @@ -159,6 +160,8 @@ int v9fs_show_options(struct seq_file *m, struct dentry
> > *root) from_kgid_munged(&init_user_ns, v9ses->dfltgid));
> >  	if (v9ses->afid != ~0)
> >  		seq_printf(m, ",afid=%u", v9ses->afid);
> > +	if (v9ses->ndentry_timeout != 0)
> > +		seq_printf(m, ",ndentrytmo=%d", v9ses->ndentry_timeout);
> >  	if (strcmp(v9ses->uname, V9FS_DEFUSER) != 0)
> >  		seq_printf(m, ",uname=%s", v9ses->uname);
> >  	if (strcmp(v9ses->aname, V9FS_DEFANAME) != 0)
> > @@ -337,6 +340,10 @@ int v9fs_parse_param(struct fs_context *fc, struct
> > fs_parameter *param) session_opts->session_lock_timeout =
> > (long)result.uint_32 * HZ; break;
> > 
> > +	case Opt_ndentrytmo:
> > +		session_opts->ndentry_timeout = result.int_32;
> > +		break;
> > +
> >  	/* Options for client */
> >  	case Opt_msize:
> >  		if (result.uint_32 < 4096) {
> 

Thanks,

-- 
Remi