On Sun, Dec 23, 2012 at 08:01:46PM +0001, Jason McIntyre wrote: > On Sun, Dec 23, 2012 at 08:17:01PM +0100, Jan Stary wrote: > > > > Yes, on the _client_ (sorry, I should have been explicit). > > What got me trying it is that sysctl(8) says > > > > To adjust the number of kernel nfsio threads > > used to service asynchronous I/O requests on > > an NFS _client_ machine. > > > > Your diff seems to imply that this affects the _server_. > > > > However, on the client, vfs.nfs.iothreads jumps to 4 > > as soon as I mount the NFS share. On the server, it stays at -1. > > > > On the client, when I start copying from the server, it stays at 4; > > on the server it stays at -1. Same when I copy the other way round. > > > > So it really seems to affect the client (as sysctl(8) currently says), > > which I think makes your diff incorrect. > > > > After I unmount the share on the client, vfs.nfs.iothreads > > stays on 4; I set that manually to -1, and it jumps to 20, > > without even having anything NFS-mounted. Is that intended? > > Setting it manually to anything but -1 then panicked my > > 5.2/i386 client. (I would try current, but that's currently > > not bootable on my i386 laptop.) > > > > ok, so unless someone steps up and explains to me how this is meant to > work i can;t do much... >
so after some help from blambert, i've committed a doc fix. i've not documented the fact that -1 is kind of the default. i'm not sure if explaining it is that helpful. nor do i know why it's done this way. as to the behaviour you're seeing whilst fiddling with the sysctl, i can't help you there i'm afraid. jmc
