The size of the actual READDIRPLUS requests is completely unaffected bySorry to be imprecise. "Size of request" should be "size of response" or "cost of request". The meaning is clear, I think.
your patch. Your change actually means that the client will continue to
use READDIRPLUS on very large directories instead of falling back to
readdir.
If you want a faster readdir(), you will find that splitting those hugeAgreed 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.
directories up into smaller subdirs is an alternative solution that
tends to scale much better on both client and server.
Having hundreds of mount options for minor tweaks is not an acceptableRegarding 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. ;-)
practice. Each mount option needs to be abundantly justified.
Since we're talking about what is really a quite arbitrary limit, I canFair enough. A proc entry to alter this globally would be an acceptable compromise for me, even if my local sysadmins might not like it.
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.