I received an error on the system console log
"vmunix: dquot table is full"
I also had some side effects manipulating files.
I guessed that maxusers was not large enough and rebuilt a kernel. I haven't
had any problems since.
Jim Palfreyman jim_at_orac.ecc.tased.edu.au also suggested this.
Dr. Tom Blinn <tpb_at_zk3.dec.com> appears to have
verified this in great detail with source code excerpts. It
turns out that dquot table entries are allocated in a fixed sized
table which is based on NVNODE. It would appear that the table size should
be dynamic as is the number of vnodes (in 3.0).
This appears to be a bug and will be reported as such.
The simple fix is to up the maxusers parameter and rebuild as NVNODE is based
on NPROC and MAXUSERS.
This answered the first of my three questions. The other 2 remain unresponded
to and are :
2) whether the quota mechanism cares whether the potential disk consumption
exceeds physical availability. ( I assume oversubsrcibing is OK )
and for future reference
3) whether the quotactl call works with the Advanced File system. The man
page for quotactl references UFS only (indirectly) but the man page for
vquota references quotactl.
Thanks also to Nigel Harwood < nharwood_at_cnw0g.cdes.com.au> for responding
with a pure SVR4 perspective, which would be to change the NDQUOT value.
--
-----------------------------------------------------------------
Todd Acheson
Ohio University
CSC room 209
Athens, OH 45701
(614)593-0034
acheson_at_oak.cats.ohiou.edu
Received on Wed Jan 04 1995 - 12:01:08 NZDT