All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs@lists.linux.dev, Remi Pommarel <repk@triplefau.lt>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Eric Van Hensbergen <ericvh@kernel.org>,
	Latchesar Ionkov <lucho@ionkov.net>
Subject: Re: [PATCH v3 2/4] 9p: Add mount option for negative dentry cache retention
Date: Wed, 4 Mar 2026 06:45:35 +0900	[thread overview]
Message-ID: <aadWf2Ox2YXdy0Yl@codewreck.org> (raw)
In-Reply-To: <4490625.ejJDZkT8p0@weasel>

Christian Schoenebeck wrote on Tue, Mar 03, 2026 at 03:53:47PM +0100:
> > +	fsparam_string	("source",		Opt_source),
> > +	fsparam_u32hex	("debug",		Opt_debug),
> > +	fsparam_uid	("dfltuid",		Opt_dfltuid),
> > +	fsparam_gid	("dfltgid",		Opt_dfltgid),
> > +	fsparam_u32	("afid",		Opt_afid),
> > +	fsparam_string	("uname",		Opt_uname),
> > +	fsparam_string	("aname",		Opt_remotename),
> > +	fsparam_flag	("nodevmap",		Opt_nodevmap),
> > +	fsparam_flag	("noxattr",		Opt_noxattr),
> > +	fsparam_flag	("directio",		Opt_directio),
> > +	fsparam_flag	("ignoreqv",		Opt_ignoreqv),
> > +	fsparam_string	("cache",		Opt_cache),
> > +	fsparam_string	("cachetag",		Opt_cachetag),
> > +	fsparam_string	("access",		Opt_access),
> > +	fsparam_flag	("posixacl",		Opt_posixacl),
> > +	fsparam_u32	("locktimeout",		Opt_locktimeout),
> > +	fsparam_flag	("ndentrycache",	Opt_ndentrycache),
> > +	fsparam_u32	("ndentrycache",	Opt_ndentrycachetmo),
> 
> That double entry is surprising. So this mount option is supposed to be used
> like ndentrycache=n for a specific timeout value (in ms) and just ndentrycache
> (without any assignment) for infinite timeout. That's a bit weird.

Could make it a s32 and say <0 means infinite? I think we have that
somewhere

> Documentation/filesystems/9p.rst should be updated as well BTW.
> 
> Nevertheless, like mentioned before, I really think the string "timeout"
> should be used, at least in a user visible mount option. Keep in mind that
> timeouts are a common issue to look at, so it is common to just grep for
> "timeout" in a code base or documentation. An abbrevation like "tmo" or
> leaving it out entirely is for me therefore IMHO inappropriate.
> 
> You found "ndentrycachetimeout" too horribly long, or was that again just
> motivated by the code indention below? I personally find those indention
> alignments completely irrelevant, not sure how Dominique sees that.
> Personally I avoid them, as they cost unnecessary time on git blame.

I rarely use blame at all and it's possible to ignore whitespaces for
blame, but I'd tend to agree here, I don't care if this stays aligned.

OTOH ndentrycachetimeout as a mount option is a mouthful,
negativetimeout or negtimeout sounds clear enough to me?
I can't think of anything else that'd be negative related
to timeouts, but perhaps it's the lack of sleep speaking

-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2026-03-03 21:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27  7:56 [PATCH v3 0/4] 9p: Performance improvements for build workloads Remi Pommarel
2026-02-27  7:56 ` [PATCH v3 1/4] 9p: Cache negative dentries for lookup performance Remi Pommarel
2026-03-04 12:50   ` Christian Schoenebeck
2026-02-27  7:56 ` [PATCH v3 2/4] 9p: Add mount option for negative dentry cache retention Remi Pommarel
2026-03-03 14:53   ` Christian Schoenebeck
2026-03-03 21:45     ` Dominique Martinet [this message]
2026-03-04  8:25       ` Remi Pommarel
2026-03-04  9:01         ` Christian Schoenebeck
2026-03-04  9:16           ` Dominique Martinet
2026-03-04 12:45   ` Christian Schoenebeck
2026-02-27  7:56 ` [PATCH v3 3/4] 9p: Set default negative dentry retention time for cache=loose Remi Pommarel
2026-03-04 12:54   ` Christian Schoenebeck
2026-02-27  7:56 ` [PATCH v3 4/4] 9p: Enable symlink caching in page cache Remi Pommarel
2026-03-04 13:01   ` Christian Schoenebeck

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=aadWf2Ox2YXdy0Yl@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=ericvh@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --cc=repk@triplefau.lt \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.