Messages in this thread | | | Date | Fri, 07 Mar 2008 16:04:05 -0500 | From | Kyle Rose <> | Subject | Re: READDIRPLUS max mount option |
| |
> 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 > readdir. > 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.
Kyle
| |