On 5/7/25 3:42 AM, Christoph Hellwig wrote:
> On Tue, May 06, 2025 at 09:52:06AM -0400, Chuck Lever wrote:
>>> Are you going to wire this up to a config file in nfs-utils that
>>> gets set before the daemon starts?
>>
>> That's up to SteveD -- it might be added to /etc/nfs.conf.
>
> Well, you should be talking to him or even include a patch.
On this list, we post nfs-utils patches separately, once the kernel API
is nailed. Steve doesn't pull such changes until the kernel changes
have been merged.
But see below: I'm still not convinced this is a tunable that is worth
going to that level of trouble for.
>>> Because otherwise this is a pretty horrible user interface.
>>
>> This is an API that has existed forever.
>
> Huh? It is a brand new file added by this patch.
/proc/fs/nfsd/max_block_size was added by commit 596bbe53eb3a ("[PATCH]
knfsd: Allow max size of NFSd payload to be configured") in 2006.
Or are you referring to something else?
>> I don't even like that this maximum can be tuned. After a period of
>> experimentation, I was going to set the default to a higher value and
>> be done with it, because I can't think of a reason why it needs to be
>> shifted up or down after that.
>
> Why not? A tiny desk NAS box has very different resources available
> compared to say a multi-socket enterprise AI data server.
I don't believe system memory size is a concern.
a. max_block_size is automatically reduced on small memory systems. See
nfsd_get_default_max_blksize().
b. The extra memory allocation is per thread, so a smaller server can
reduce the standing memory requirements by lowering the number of
nfsd threads.
c. we're now removing rq_vec, so there's already less memory to allocate
than before.
--
Chuck Lever
