Re: per-mount maxvnodes
> Therefore comes the idea to have a per-mount maxvnodes. > I tried implementing it, the biggest problem is how to set the value. sysctl kern./usr/local.maxvnodes? It's a little ambiguous, in that it's possible - or at least it was last time I tried it - to have multiple mounts with the same mounted-on string. But that's definitely an unusual case, and I see nothing wrong with accessing the topmost mount in that case; that's what normal filesystem accesses will do, after all. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: per-mount maxvnodes
On Thu, Jun 07, 2012 at 11:09:26AM -0400, Mouse wrote: > > I tried implementing it, the biggest problem is how to set the value. > > sysctl kern./usr/local.maxvnodes? And what about filesystem with dots in the path? -- Emmanuel Dreyfus m...@netbsd.org
Re: per-mount maxvnodes
On Thu, Jun 07, 2012 at 11:09:26AM -0400, Mouse wrote: > > Therefore comes the idea to have a per-mount maxvnodes. > > > I tried implementing it, the biggest problem is how to set the value. > > sysctl kern./usr/local.maxvnodes? > > It's a little ambiguous, in that it's possible - or at least it was > last time I tried it - to have multiple mounts with the same mounted-on > string. But that's definitely an unusual case, and I see nothing wrong > with accessing the topmost mount in that case; that's what normal > filesystem accesses will do, after all. No, I think this should be a mount option. Maybe it's time to revisit the mount(2) interface (proplist anyone ? :) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: per-mount maxvnodes
On Thu, 7 Jun 2012 17:50:58 +0200 Manuel Bouyer wrote: > On Thu, Jun 07, 2012 at 11:09:26AM -0400, Mouse wrote: > > > Therefore comes the idea to have a per-mount maxvnodes. > > > > > I tried implementing it, the biggest problem is how to set the value. > > > > sysctl kern./usr/local.maxvnodes? > > > > It's a little ambiguous, in that it's possible - or at least it was > > last time I tried it - to have multiple mounts with the same mounted-on > > string. But that's definitely an unusual case, and I see nothing wrong > > with accessing the topmost mount in that case; that's what normal > > filesystem accesses will do, after all. > > No, I think this should be a mount option. Maybe it's time to revisit the > mount(2) interface (proplist anyone ? :) If mounts had an ID (like processes), then it'd be easier to use sysctl for them (commands such as mount and df might want to also export such IDs, so possibly also statvfs(2))... There are device ID, but I'm not sure this could serve this purpose properly. This also reminds me of the thread about possibly allowing to temporarily enable noatime for a particular operation such as a backup or find... Perhaps that such options should eventually be dynamically scoped such that a particular process or lwp could temporarily bind another value for its own use (if it has the necessary privileges, of course)? I'm not sure how far fetched this can be relatively to the code, I'm not very familiar with the FS code. -- Matt
