Messages in this thread | | | Subject | Re: nfsiod issues? | Date | Tue, 16 Apr 1996 10:05:50 +0200 | From | Olaf Kirch <> |
| |
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.
| |