} Logan) (02/16/88)
Hello, I have a small problem which someone might be able to solve: After receiving large amounts of mail, filling up my account several times, and doing other things which have pushed my storage to the limit, whenever I do a SHOW QUOTA, I get a "blocks used" which is higher that the blocks used count which I get with a dir/full. This is true even when blocks which are allocated but not filled are taken into account (such as a one block file which is allocated 3 blocks). Has anyone else run into this? How can I fix it? Thanks in advance. ------------------------------------------------------------------- | Stay alert! | The Computer is: Scott I. Logan | | Trust no one! | BITNET: CHAA0024 @ DALAC | | Keep your laser handy! | UUCP: logan @ dalcsug.uucp | | The Computer is your friend! | Logical device: SLOG | -------------------------------------------------------------------
cfchiesa@bsu-cs.UUCP (Sir Xetwnk) (02/25/88)
In article <346@dalcsug.UUCP>, logan@dalcsug.UUCP writes: > > [circumstances leading to disk-quota fill-up > > ... whenever I do a > SHOW QUOTA, I get a "blocks used" which is higher that the blocks used count > which I get with a dir/full. This is true even when blocks which are allocated > but not filled are taken into account (such as a one block file which is > allocated 3 blocks). > > Has anyone else run into this? How can I fix it? Yes, I run into this all the time, working for COmputing Services "help desk" user assistance dept... The standard answer is as follows. Because of the way VMS manages files, there is an "invisible" overhead of disk usage that doesn't show up when you do any form of DIR/SIZE, but which IS charged against your disk quota and therefore DOES show up when you do a SHOW QUOTA. This invisible overhead amounts to A MINIMUM of ONE BLOCK PER FILE AND PER DIRECTORY - and can easily be MORE than this. To find out where you REALLY stand, do the following. 1) Go to your main directory (SET DEFAULT SYS$LOGIN). 2) DIR/SIZE=ALL [...]*.*;* This will list all your directories and files, and will give you a final count of "# directories," "# files," and "blocks used." 3) ADD UP the "# directories," "# files," and "blocks used" (three quan- tities). 4) Compare THIS total against what SHOW QUOTA tells you - it should be MUCH closer. If not, THEN you have a problem -- write us again. In most cases, I never hear from the person again. In fact, many times, this method seems to say that the person is getting charged for FEWER blocks than SHOW QUOTA says, and the user keeps their mouth shut so as not to lose "a good thing!" Only in relatively rare cases does a user have a file stored in a directory they don't know about in another area. (Files are charged against the disk quota of the username CREATING the file, NOT that of the directory in which the file itself is placed!) Chris Chiesa, Senior, CS Dept., Ball State University, Muncie, IN -- <><><><><><><><><><><><><><><><><><><><><><><><><><><><> Chris Chiesa <><><><><> <> {ihpn4|seismo}!{iuvax|pur-ee}!bsu-cs!cfchiesa <> <> cfchiesa@bsu-cs.UUCP <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
dave@wsccs.UUCP (Dave E Martin "VAX Headroom") (03/02/88)
Have you tried running diskquota, doing use $MYDISK:, and rebuild? or analyze/disk/repair?
crouch@btnix.UUCP (Chris Rouch) (03/03/88)
From article <346@dalcsug.UUCP>, by logan@dalcsug.UUCP: > > > Hello, I have a small problem which someone might be able to solve: > > doing other things which have pushed my storage to the limit, whenever I do a > SHOW QUOTA, I get a "blocks used" which is higher that the blocks used count > which I get with a dir/full. This is true even when blocks which are allocated > but not filled are taken into account (such as a one block file which is > allocated 3 blocks). > I have not heard of a system where the diskquota total matches the total actually used. However diskquota takes notice of files you own anywhere on the disk, not just in your directory tree, so if you use something like CMS, this may distort your diskquota figure even more. Chris Rouch -------------------------------------------------------------------------------- vax to vax (UUCP) CRouch@axion.bt.co.uk (...!ukc!btnix!crouch) desk to desk RT3124, 310 SSTF, British Telecom Research Laboratories, Martlesham Heath, IPSWICH, IP5 7RE, UK. voice to voice +44 473 646093 "Ours is not to look back, ours to continue the crack." --------------------------------------------------------------------------------