Several weeks ago I posed the follwoing question:
> Several of our users have recently been complaining that the value reported
> by the quota system for disk space usage does not agree with that reported by
> du. For example:
> altair:/ 4 # quota -v tdubins
> Disk quotas for tdubins (uid 113):
> Filesystem usage quota limit timeleft files quota limit timeleft
> /u3 5748 5000 10000 2.8 days 37 0 0
> altair:/ 5 # du -s ~tdubins
> 2131 /home/csci/tdubins
> A "find -user tdubins /u3" reports that the only files owned by this user
> reside in his home directory.
> My problem is that running quotaoff, quotacheck, quotaon does not bring these
> values into agreement. Can somebody please tell me why not.
Several people pointed out the difference in the way quota and du report
space usage. However cupie dolls go out to Ian Angles for his comment about
multiple quota daemons (now as to why there was more than one daemon running
is another question) and Rob Quinn for mentioning possible file corruption
(the server had not been booted or the filesystems checked in 84 days). My
thanks to all who replied.
> From: Neil W Rickert <rickert@cs.niu.edu>
>
> du only reports space in directories.
>
> quota reports all space. (You may have a command 'quot' to do this also).
>
> Suppose that a program:
>
> 1: opens a file
> 2: unlink()s the file
> 3: continues executing.
>
> Then the space of that file is counted by quota, but not by du.
>
> =======================================================================
>
> From: Claus Assmann <ca@idefix.informatik.uni-kiel.dbp.de>
>
> I had a similar problem over here.
> I found that hardlinks were a case for this:
> If someone has a hardlink for a file owned by you,
> and you 'rm' this file, your quota won't drop !
>
> But you should 'find' the file, so I'm not sure, if
> this is the reason of your problem
> (Example:
> % ls -s
> 952 log-5.00.tar.Z
> % quota -v
> /home2 5507 200000 220000 114 10000 20000
> % du -s .
> 5507
> % rm log-5.00.tar.Z
> % quota -v
> /home2 5507 200000 220000 114 10000 20000
> % du -s .
> 4555 .
> another user has a hardlink for log-5.00.tar.Z !)
>
> =======================================================================
>
> From: Malcolm.Harper@prg.oxford.ac.uk
>
> We have a similar problem. This behaviour occurs if a file
> is still open, but not entered in a directory -- in our case
> one of our users uses Lotus Agenda from a PC-NFS linked PC,
> and has left lots of temporary files "open". I believe that
> the situation will be cleared up (temporarily) by a server
> reboot. You can see which files are lost by running fsck
> (I'd recommend "fsck -n") on the server's disk partition, and
> this may help to find which application is badly behaved.
>
> I don't know of a solution other than rebooting (or shutting down
> enough to make running fsck a safe activity...).
>
> The unref'd files show up in the kernel inode table (as
> shown by "pstat -i") incidentally. I assume that the files
> are held open by the nfsd daemon processes.
>
> For now, we're increasing the user's quota until the problem
> can be resolved :-(
>
> =======================================================================
>
> From: nash@ucselx.sdsu.edu
>
> There can be 2 reasons. From the size difference, I'd say both apply here.
> 1) du gives the amount of space used, vs df and quota giving the amount
> of space allocated. He would have to have a lot of very small files
> (under 1k in size) to come up with this difference. Quota only shows
> 37 files under /u3.
>
> 2) He or root has created files in another directory under /home with his
> UID. Try running "find /home -user tdubins -print" as quota is showing
> you files under /home, not /u3. (if /home/csci is a symbolic link to
> /u3 then I'm also puzzled)
>
> =======================================================================
>
> From: Ian Angles <ia@st-andrews.ac.uk>
>
> Check to see if you have more than one rpc.rquotad running - we had a
> problem like this which went away after removing the second (blocked)
> process and running quotacheck & co.
>
> =======================================================================
>
> From: fritchie@stolaf.edu (Scott E. Fritchie)
>
> We've been having the same problems, too. Our fileservers are SS2's
> running SunOS 4.1.2. They've been up for about 27 days now, and some
> accounts really have some messed up quota information. Running
> "quotacheck -a -v" doesn't seem to do anything (no output to stdout or
> stderr, exit status 0).
>
> Just checking something now, I think I may have found a solution to
> our problem: I used "quotacheck -v /messed/up/filesystem" explicitly
> and got:
>
> *** Checking quotas for /dev/rsd1h (/nfs/home/accserv1/stub)
> millerj fixed: files 563 -> 565 blocks 11798 -> 12514
> ...
> hintonj fixed: files 172 -> 150 blocks 6298 -> 1390
>
> Mr. Hinton is a much happier user now. :-)
>
> This leaves the root cause of the problem unknown, but at least you've
> got something to post in your followup....
>
> =======================================================================
>
> From: rjq@phys.ksu.edu (Rob Quinn)
>
> Two things
> reboot - perhaps the file system is corrupted.
> If you erase a file that is open, the space is not free'd until
> the file is closed.
-- Pat Macdonald, Computer Services, University of Manitoba Phone: (204) 474-9870 FAX: (204) 275-5420
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:45 CDT