[lkml]   [1996]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: nfsiod issues?
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 Kirch | --- o --- Nous sommes du soleil we love when we play | / | \ sol.dhoop.naytheet.ah
For my PGP public key, finger

 \ /
  Last update: 2005-03-22 13:37    [W:0.028 / U:1.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site