[2262] in Kerberos
Re: Kerberized NFS
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Wed Oct 7 11:21:13 1992
Date: 7 Oct 92 14:01:39 GMT
From: mamros@athena.lkg.dec.com (Shawn Mamros)
Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
To: kerberos@shelby.Stanford.EDU
john@iastate.edu (John Hascall) writes:
>What would be nice is if the maps where stored in a file as well as
>in the kernel when created (so you don't loose state over a crash)
>and some way to make "load" a lot faster (seems like it takes
>about a half second per uid-map -- and we have many hundreds at
>any given time). Someday, perhaps we will get time to look at
>this ourselves, but maybe someone else already has?
Half a second for each map sounds excessive, but then again it does have
to make one nfsmapctl(2) syscall per map. Maybe somebody should take a
closer look at how the mapping table is structured, and see if it can be
made more efficient...
As far as having the maps stored in a file as well as the kernel, it sounds
like you want to make nfsmapctl(2)'s operation more analogous to what
quotactl(2) or quota(2) (depending on your flavor of OS) does. That might
not be a bad idea... adding NFSMC_ON (which you would need to sync up the
kernel's copy with what's in the file at boot time) and NFSMC_OFF would
clean up parts of nfsc nicely (where, for "enable" and "disable" to work,
you have to write to kernel memory... ick). Of course, nfsmapctl(2) is
used much more frequently than quotactl(2), so it's not clear whether this
will help performance more than it hurts (quicker startup/load time, perhaps,
but possibly slower map/unmap operations if you have to sync the file).
This is all off the top of my head - I haven't really looked too closely
at any of this, but would be interested in anybody else's comments/suggestions.
Maybe I'll get a chance to do a closer look sometime soon...
-Shawn Mamros
DECathena engineering
E-mail to: mamros@athena.lkg.dec.com
