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
