On Dec 21 19:01:44, j...@kerhand.co.uk wrote: > On Fri, Dec 21, 2012 at 02:34:50PM +0100, Jan Stary wrote: > > On 5.2/i386, man sysctl says > > > > To adjust the number of kernel nfsio threads used to service > > asynchronous > > I/O requests on an NFS client machine: > > > > # sysctl vfs.nfs.iothreads=4 > > > > The default is 4; 20 is the maximum. See nfssvc(2) and nfsd(8) for > > further discussion. > > > > Does it still apply? The default now seems to be > > > > # sysctl vfs.nfs.iothreads > > vfs.nfs.iothreads=-1 > > > > which scales itself to 4 when I copy a file from a NFS server. > > Should I be touching vfs.nfs.iothreads manually? > > Setting it to 20 just panicked my 5.2/i386. > > > > Also, neither nfssvc(2) nor nfsd(8) seems > > to contain any "further discussion" of this. > > > > i get -1 here too. but you;re saying that the value changes to 4 when > transferring, right?
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.) Jan