Re: [PATCH 0/2] Introduce dns_interval procfs setting

[Tom Talpey <tom@talpey.com>]

On 6/9/2022 11:03 AM, Enzo Matsumiya wrote:
> On 06/09, Tom Talpey wrote:
>> On 6/8/2022 5:54 PM, Enzo Matsumiya wrote:
>>> Hi,
>>>
>>> These 2 patches are a simple way to fix the DNS issue that
>>> currently exists in cifs, where the upcall to key.dns_resolver will
>>> always return 0 for the record TTL, hence, making the resolve worker
>>> always use the default value SMB_DNS_RESOLVE_INTERVAL_DEFAULT
>>> (currently 600 seconds).
>>>
>>> This also makes the new setting `dns_interval' user-configurable via
>>> procfs (/proc/fs/cifs/dns_interval).
>>>
>>> One disadvantage here is that the interval is applied to all hosts
>>> resolution. This is still how it works today, because we're always using
>>> the default value anyway, but should someday this be fixed, then we can
>>> go back to rely on the keys infrastructure to cache each hostname with
>>> its own separate TTL.
>>
>> Curious, why did you choose a procfs global approach? Wouldn't it be
>> more appropriate to make this a mount option, so it would be applied
>> selectively per-server?
> 
> I tried to stick to the current behaviour, while also fixing the issue
> of getting a TTL=0 from key.dns_resolver upcall.
> 
> A mount option looks indeed better initially, and that was also my
> initial approach to this. But in a, e.g. multi-domain forest, with
> multiple DFS targets, the per-mount setting starts to look irrelevant
> again as well. So I took the "per-client" approach instead.

Ok, I guess. It seems like kicking the can down the road, a little.
I agree that rearchitecting the DNS cache might be extreme, but many
distros consider procfs to be a user API, and they'll require it to
be supported basically forever. That would be unfortunate...

Tom.