Quotas: a catch 22

[Kennedy Lemke]

[I posted this to comp.sys.admin originally a couple weeks ago but
 got no responses.  I hope someone can help; if you're interested,
 please read the whole article before replying.  Thanks -- kjl].

Often times (it has been difficult to determine the exact
circumstances), the "quota" program seems to take interminably
long to execute--in fact, up to several minutes.  And since
quota is built into the login program (rightfully so, in my
opinion), it can thus take this long to log into our cycle
server machine.

For our site, the use of the quota command requires a call to
rpc.rquotad on our NFS server, since home file systems are
all nfs-mounted.  I've trace(1)'d the rpc.rquotad command and
haven't seen anything unusual, except that the execution seems
slow (and that rpc.rquotad seems to be doing much more work
that I think it needs to do).

Obviously when it takes several minutes, or even more than
about 30 or 60 seconds, to log into our cycle server, our users
complain.  To solve this problem, I replaced /usr/ucb/quota
with a shell script that does an exit 0 when called with no
arguments, or executes "quota.exe -v" when called with a "-v"
flag (quota.exe is the sparc executable).

And logging into the cycle server then becomes very fast.  But
then after a couple days, I again start getting complaints from
our users that now they have gone over their quota and hadn't
been notified of this fact upon login.  So I change the programs
back again (move the real quota back into place), and all is
fine until logging in becomes interminably slow again.  And so
on, and so on.

Surely others have experienced the same thing.  I'd like to
be enlightened on two things: first, is the culprit of this
activity really an inefficient rpc.rquotad?  Second, what is
the best solution to this problem?  Installing a login that
doesn't call "quota" is not an option.  Is there a more
efficient rpc.rquotad around, or do I need to write my own?
Or should I simply leave the shell script in place and concentrate
on educating my users (3700 of them).  Please give me suggestions,
and please respond via email since I can't read this group as
often as I'd like to.  I'll summarize if there is interest.
Thanks.
				Kennedy Lemke
				Systems Programmer
				CIT--87 Prospect
				Princeton University
				Princeton, New Jersey  08544

Work Phone: (609) 258-6033      Internet: lemke at Princeton.EDU
Fax Phone:  (609) 258-3943      uucp:     ...rutgers!princeton!lemke
Home Phone: (609) 275-7298      Bitnet:   LEMKE at PUCC.BITNET