Re: [PATCH v3 2/4] 9p: Add mount option for negative dentry cache retention

[Dominique Martinet]

Christian Schoenebeck wrote on Wed, Mar 04, 2026 at 10:01:42AM +0100:
> > I did that on previous version, but was afraid that ~20days timeout max
> > value may be too restrictive?
> > 
> > I do agree that this is a bit odd though and if you both think s32 is
> > better that is fine with me.
> 
> What about just making this mount option a string and doing the parsing on our
> end? That would have the benefit of simply allowing arguments like "i00s",
> "5d", "1y", and if you really wanted "inf".
> 
> I would find units for this much more useful in practice than allowing
> infinite. Like discussed before, it is in general a bad idea to configure
> negative dentries to persist for good due to the huge amount of bogus entries
> that pile up.

I don't mind either way -- I think 20 days for such a timeout is enough,
but I agree being able to set something like '60s' or '100ms' would
certainly be convenient.

I'm actually surprised there's no such parsing helper in the kernel?!
The only related code I could find was parse_ns_duration /
parse_seconds_duration in tools/tracing/rtla/src/utils.c but that's for
tools, and there doesn't seem to be anything we could use..

Well, it's not that bad, so I'm not fussy here.


> > > 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
> > 
> > No strong opinion on the option name though so any name that suits you
> > is alse fine by me.
> 
> Another suggestion: "ndtimeout"?

I'd slightly favor negtimeout over ndtimeout but am fine with either
here.
('nd' sounds like something network-y to me, network discovery or ndo,
but that's not a hard no)


Thanks,
-- 
Dominique Martinet | Asmadeus