> The size of the actual READDIRPLUS requests is completely unaffected by
> your patch. Your change actually means that the client will continue to
> use READDIRPLUS on very large directories instead of falling back to
Sorry to be imprecise. "Size of request" should be "size of response"
or "cost of request". The meaning is clear, I think.
> If you want a faster readdir(), you will find that splitting those huge
> directories up into smaller subdirs is an alternative solution that
> tends to scale much better on both client and server.
Agreed that this is probably the least terrible of the available
solutions, but in my specific case it requires a more extensive
modification to my software than the relatively minor kernel change.
> Having hundreds of mount options for minor tweaks is not an acceptable
> practice. Each mount option needs to be abundantly justified.
Regarding your straw man, nobody's proposing hundreds of mount options.
I imagine the effort required to implement each one would keep such a
thing from happening. ;-)
> Since we're talking about what is really a quite arbitrary limit, I can
> certainly see an argument for why we might want a way to change it, but
> I'm still not convinced that we need to be setting this parameter at the
> mountpoint level.
Fair enough. A proc entry to alter this globally would be an acceptable
compromise for me, even if my local sysadmins might not like it.