Re: nfsiod issues?

Olaf Kirch (okir@monad.swb.de)
Tue, 16 Apr 1996 10:05:50 +0200


On Mon, 15 Apr 1996 23:18:31 CDT, "Larry 'Daffy' Daffner" wrote:
> I am assuming that from a process standpoint, the nfsiod code looks
> like a normal process with it's memory space mapped into kernel space,

Almost. Kernel threads are not subject to pre-emptive scheduling, so you
`just' have to make sure that you keep your data consistent between
operations that call schedule() or sleep_on().

Using daemons for NFS readahead is an old and admittedly ugly concept;
if you have a better idea how to do, I'd sure want to know.

I'm working on redoing the nfsiod support at the moment so that only
one nfsiod is required rather than n.

> In addition, the locking of insmod's memory and command line look bad
> and are confusing unless you have read the README.

Agreed. That's on my todo list, but rather towards the bottom of it.
> Also, what about loading/unloading the nfs module. Is it really the
> only viable solution to keep the nfsiod's around and the nfs.o module
> loaded until said processes are killed?

No, you can use nfs without nfsiod. The performance will just be what it
used to be before adding readahead.

> It seems strongly against the concept of loadable modules to me,
> especially with kerneld.

In this case, probably kerneld should be fixed to run `killall -TERM nfsiod'
before unloading the module.

Olaf

-- 
Olaf Kirch         |  --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de  |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
             For my PGP public key, finger okir@brewhq.swb.de.