[comp.os.vms] VMS diskquota synchronization.

PERAINO@GMUVAX.BITNET (02/17/88)

        Greetings. I am having a problem with VMS disk quotas. It usually
goes something like this. Someone comes to me and says, "The system
says I'm out of space, but I should have plenty more". I check diskquota.
It says the person is using 2489 of 2500 (or something like that). I
go to his home directory and do a DIR/SIZE/GRAND [...]  and sure enough
it only comes up with 2000. About 500 blocks off. Fine. I figure maybe
the guy owns files elsewhere. I go to the top of the device and do a
DIR/SIZE/GRAND/BY=username [000000...]  and it still only comes up with
2000 blocks. Fine. I go back to diskquota and do a REBUILD on that device.
Nothing changes. The guy is being charged for about 500 more blocks than he is
really using. This has happened on more than one account. Maybe the
answer is simple, and I'm missing it, but what the hell is going on?

peraino@gmuvax.

draughn@iitmax.UUCP (Mark T. Draughn) (02/24/88)

In article <8802210031.AA25550@ucbvax.Berkeley.EDU> PERAINO@GMUVAX.BITNET writes:
> [ $ SHOW QUOTA not equal to $ DIR/SIZE ]

There are a whole bunch of ways this can happen.  The author of the article
tried some of these, but I thought I'd repeat them.  This can be really arcane
but here goes...

1) DIR/SIZE shows the amount of the file that is USED.  More space may
   have been ALLOCATED but not yet written to.  Many VMS systems allocate
   space in a multiple of some small integer, usually 3.  Consequently,
   100 files that are only 1 block long will use 300 blocks.  Use
   DIR/SIZE=ALLOCATION to see actual allocations.  Some programs
   allocate hundreds of blocks but only use a few and don't truncate
   the file.

2) There may be files in directories other than the ones you searched.
   Try searching the entire disk with something like
   DIR [*...] /BY_OWNER=whatever /SIZE=ALLOCATION

3) The disk quota information may be corrupted.  Run DISKQUOTA and use
   the REBUILD command.  (This will lock out a lot of disk-related activity
   which may bother other users.)

4) There may be files which do not appear in any directory.  This is not
   really a structural problem in the file system.  Many temporary files
   are created in no directory.  Sometimes the programs that create them
   do not delete them.  This can also happen by accident or because of crashes.
   The command ANALYZE/DISK can find these files.  It will put them in the
   [SYSLOST] directory.  This has a side affect of rebuilding the quotas
   and it locks the disk.  Read the instructions first.

5) The disk structure may be corrupted and DIR may not be able to find all
   of the files for some reason.  Again, ANALYZE/DISK fixes this.

6) Don't forget that directories themselves take up space.  Easy to forget
   if you are only looking in one directory.  (I.e. If creating a file causes
   more of a chnage than you thought it should, the directory file may have
   gotten bigger when the file was added.)

7) The headers for all the files are stored in [000000]INDEXF.SYS which
   the file system maintains.  Every file has at least one header record in
   here and files that are badly fragmented need several records.  The quota
   system charges you for these records and if you have a lot of small files
   this can really add up.  (Even files that DIR says have a size of 0 will
   still make the quota system charge for the header.)

8) If you use volume sets and the non-primary disks weren't empty when the
   binding was done, things can get a little strange.  I imagine this can cause
   a few problems with quotas.  I don't know much about this.

9) There is a window of vulnerability built into the file system repair
   facilities (DISKQUOTA REBUILD and ANALYZE/DISK).  If the diskquota repairing
   code discovers that there are files owned by people who do not appear in
   the diskquota file ([000000]QUOTA.SYS), it will add them.  But if all the
   slots in the file are in use, it will have to extend the quota file.
   While the utility runs, file system structural changes are locked out.
   This prevents file creation, deletion, truncation, and extension.  The
   repair facility has to re-enable these activities in order to extend the
   quota file then disable them again.  Some user could slip a change through
   at this point.  (It doesn't require split-second timing because the
   locked-out operations are queued.  They could have been building up for
   several minutes.)  If you really want to be SURE, run the repair facility
   repeatedly until it runs without adding any new records to the quota file.

Let me know if I've missed anything, or if I'm out of date on anything, or if
I'm really screwed up on anything.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mark Draughn				UUCP: ...ihnp4!iitmax!draughn
Computer Science Department		BITNET: SYSMARK@IITVAX
Illinois Institute of Technology	(312) 567-5334
Chicago, Illinois  60616		This space for rent.
"If you think the United States has stood still, who built the largest
shopping center in the world?"  -- Richard Nixon

fsinf@iravcl.ira.uka.de (02/26/88)

In article <8802210031.AA25550@ucbvax.Berkeley.EDU>, PERAINO@GMUVAX.BITNET writes:
>
> It says the person is using 2489 of 2500 (or something like that). I
> go to his home directory and do a DIR/SIZE/GRAND [...]  and sure enough
> it only comes up with 2000. About 500 blocks off. (...)

Hello, your problem is easy to explain. There is a difference between allocated
blocks on disk and the EOF which is usually shown with $dir

- If I enter (being in the home directory) $dir/size/grand [...] I get the
  result 1167 blocks used.
         ^^^^
- If I enter $show quota I get the result 1504 blocks used.
                                          ++++

- I typed (in home directory) $dir/full [...] and summarized the numbers after
- I typed $dir/full [-]<user>.DIR and got: Size: 1/9; summarized to the
  previous result it makes 1167/1362
                           ^^^^
- I know computer scientists will start counting by the number ZERO. For
  every file you have there will be a zero-block; you can get stored
  information therein with $ dump/size=(start:0,count:1) <file_name>
  I have 140 file (including [-]<user>.DIR). Result: 1167/1502 (140+1362=1502)
                                                          ++++

Please don't ask me were the two missed blocks are, I realy don't know.

But I tested the following using the $show quota-command. If I set a great
number of ACLs to one file the number of used blocks will become greater.

I hope this helps
Regards, Elmar
_______________________________________________________________________________
In-Real-Life: Elmar Schuetz
              c/o Fachschaft Informatik, Karlsruhe University
              P.O. Box 6980, Am Zirkel 2, D-7500 Karlsruhe, FRG

InterNet:     fsinf@iravcl.ira.uka.de

Dislcaimer:   The opinions above are mine and do not necessarily reflect those
              of Fachschaft Informatik or Karlsruhe University. Any resemblence
              to statements found in actual reality is purely coincidental.

An expert is a man who stops thinking - he knows!	-- Frank Lloyd Wright
-------------------------------------------------------------------------------