lkml.org 
[lkml]   [2008]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-03-07 22:07    [W:0.043 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site