Messages in this thread |  | | Date | Tue, 10 Sep 1996 19:58:15 +0100 | From | Matthew J Brown <> | Subject | Re: NFS as a module / kerneld question |
| |
David Flood writes:
> And if these processes are needed, how come they just go to sleep > and never wake up?
Because they're kernel mode processes, not user mode processes. Normal rules don't actually apply.
What they do is NFS asynchronous reading. Read fs/nfs/README in the kernel source tree for more details. The number of nfsiod processes is equivalent to the number of asynchronous reads that can be in progress at once.
They aren't actually asleep; just all the code they execute is in kernel space rather than user space.
> And when another mount command is executed, a new one is forked to > handle the new mount rather than using one of the existing > processes? I can see nfs.o forking one process since it gets > loaded due to a mount command and that one nfsiod is necessary to > handle that mount. But what about the other 3? And when every nfs > mount is unmounted, the original 4 don't terminate. They just hang > around. As a result the use count of nfs.o is always some number > that is equal or greater than 4.
The number of them is nothing to do with the number of mounts, but the number of async reads that can occur at once. The fact that each one adds 1 to the nfs.o use count seems like a bug to me, though.
Basically they're a NFS performance enhancement. Most other UNIX systems have them too; for example, SunOS 4.1 has 'biod' which does a similar job.
-Matt
|  |