Problems with vquotacheck under DU 3.2c

From: Tim Mooney <mooney_at_dogbert.cc.ndsu.NoDak.edu>
Date: Tue, 16 Jan 1996 11:09:59 -0600 (CST)

All-

We've been experiencing some strange behavior from the `vquotacheck' command
under Digital Unix 3.2c, and I was wondering if anyone else had seen this
type of behavior or otherwise might be able to point out what's going wrong.

A few days ago a user complained about problems not being able to save email,
and it turned out to be a problem with her being over quota, but that wasn't
the end of it. She has a vquota on only one of several vquota'ed filesystems,
yet when root did a vquota for her, she showed up as using the same block
total on all the vquota'ed filesystems (she has a 1/1 soft/hard block limit
on all the other vquota'ed filesystems). I ran a `find' through the other
filesystems, and she owned no files on any of them.

I then tried running `vquotacheck -uav', and although that spit out lots and
lots of output, it didn't fix the problem for her on the other filesystems.
On a hunch I ran `vquotacheck -uv' on just one of the other filesystems, and
that *did* fix the problem for that particular filesystem. Its output
indicated dozens and dozens of users that had inode and block changes from some
positive number -> 0.

I then checked the vquota for my personal account on the machine. It showed
I was using 8 blocks on the one filesystem where I have a vquota. I ran
vquotacheck -vu on the filesystem in question, and my usage total went from
8 blocks to 930 blocks. I then ran vquotacheck -vu on the remaining
filesystems, and things seemed to be fine.

After rebooting the machine this morning the exact same problem returned;
running a vquota for the user who had been having troubles before again showed
her using the exact same block total on all the vquota'ed filesystems. Running
vquotacheck -auv did not fix the problem, but running vquotacheck -uv
individually for each filesystem did.

All of the fileystems in question are LSM & ADVFS. The relevant section of
/etc/fstab is:

faculty_domain#faculty /export/home/faculty advfs rq,userquota 0 2
student_domain#student /export/home/student advfs rq,userquota 0 2
ndsufaculty_dmn#ndsufaculty /export/home/faculty/ndsu advfs rq,userquota 0
2
ndsu96_dmn#ndsu96 /export/home/student/ndsu/96 advfs rq,userquota 0
2
undfaculty_dmn#undfaculty /export/home/faculty/und advfs rq,userquota 0
2
und96_dmn#und96 /export/home/student/und/96 advfs rq,userquota 0 2


As far as quota startup, I took the standard quota script in /sbin/init.d/quota
and replaced all occurrences of quotacheck with vquotacheck, quotaon with
vquotaon, etc. A symlink in /sbin/rc3.d/S01quota points to this script, and
/etc/rc.config does contain:

QUOTA_CONFIG="yes"
export DISPLAYTYPE HOSTNAME NUM_NETCONFIG QUOTA_CONFIG


After reading the man page for vquotacheck, it wasn't clear to me whether
vquotacheck can be run before vquotaon (as is the case for the UFS quota
commands) or not -- the man page says only: "Each fileset must be mounted with
quotas enabled." In any case, I've tried modifying the /sbin/init.d/quota
script so that the vquotaon command is run before the vquotacheck command, and
that didn't fix the problem.

I have opened a call with Digital's CSC, but if anyone else has seen a similar
phenomenon or has some suggestions for me, let me know. I will summarize to
the list.

Tim
-- 
Tim Mooney                              mooney_at_toons.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Bldg.                 (701) 231-8541 (FAX)
North Dakota State University, Fargo, ND 58105
Received on Tue Jan 16 1996 - 18:59:08 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT