SUMMARY: Problems with vquotacheck under DU 3.2c

From: Tim Mooney <mooney_at_dogbert.cc.ndsu.NoDak.edu>
Date: Thu, 25 Jan 1996 08:54:20 -0600 (CST)

All-

I received responses from two other people,

Kevin Lentin K.Lentin_at_cs.monash.edu.au
Seela Balkissoon seela.balkissoon_at_sheridanc.on.ca

indicating that they too were seeing problems very similar to those I had
described in the original message, included at the end of this message. Seela
has seen the problem under 3.2a, so the problem is not limited to 3.2c.

In addition, my call to Digital's CSC turned up some other information:

1) The documentation on at least the `vquotacheck' command (and possibly the
vquotaon command, I'm not certain there) is wrong, and an enhancement request
was already pending for the documentation when I opened my call to the CSC.

The problem involves (at least) the `-a' option to vquotacheck -- even if you
use `vquotacheck -av' or `vquotacheck -auv' and it *appears* to be doing
something on all the filesystems, it really isn't. It appears that rather
than checking vquotas like this:

        vquotacheck -auv

one really needs to run

        vquotacheck -u /the/file/system

individually for each vquota'ed filesystem.

2) Contrary to what I thought the man page for vquotacheck was implying, it
is ok to do the vquotacheck *before* the vquotaon -- by `quotas must be
enabled' the man page just means that filesystem must be listed as vquota'ed
in /etc/fstab.

3) The most serious problem that Seela, Kevin, and I have each experienced
I still have no more information on. The problem is that the vquota*
commands will sometimes (but not always) incorrectly give one or more users
a block usage on filesystems on which they own no files and have a 1/1
soft/hard block limit (ie they don't have access to that filesystem). On one
of the filesystems (the filesystem that they have access to) that block usage
is correct; on all the other filesystems they are credited for using the same
number of blocks, even though they really aren't.

This problem may have been a symptom of the way that we were starting vquotas
on those filesystems -- I haven't noticed it occurring since I switched to
checking and activating quotas by individual filesystem. If I do notice it
happening again, I will investigate it further with Digital. For now, vquota's
can be checked and enabled by changing the `start' stanza in the
/sbin/init.d/quota file to look something like this:


#
# setup or shutdown disk quotas
#
case $1 in
'start')
    if [ "$QUOTA_CONFIG" = 'yes' ]; then
        if [ -f /usr/sbin/vquotacheck ]; then
            echo "Checking ADVFS disk quotas"
            #/sbin/quotacheck -a
            for i in `/usr/bin/grep 'rq,userquota' /etc/fstab | grep 'advfs' | awk '{ print $2}'
            do
                /usr/sbin/vquotacheck -u $i
            done
        else
            echo "$0: /usr/sbin/vquotacheck does not exist"
            exit 1
        fi
        if [ -f /usr/sbin/vquotaon ]; then
            echo "Enabling ADVFS disk quotas"
            #/usr/sbin/quotaon -a
            for i in `/usr/bin/grep 'rq,userquota' /etc/fstab | grep 'advfs' | awk '{ print $2}'
            do
                /usr/sbin/vquotaon -u $i
            done
        else
            #echo "$0: /usr/sbin/quotaon does not exist"
            echo "$0: /usr/sbin/vquotaon does not exist"
            exit 1
        fi
    fi
        ;;


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
----original message follows----
) 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 Thu Jan 25 1996 - 17:08:24 NZDT