SY$LEE@CUCHEM.CHEM.COLUMBIA.EDU (TIM M. LEE) (07/22/87)
Greetings, I have the following problem which is that there is a difference between diskquota and "dir /by_owner /size /grand". Using the diskquota facility, I see that a user has 48,976 blocks allocated to him but when I do a directory by ownership, there are only 42,578 blocks owned by him. Thus there is a difference of 6,398 unaccountable blocks. I used the rebuild option of the diskquota facility and that didn't change anything. Thus does anyone have suggestions or ideas where those blocks may be. I am aware that some blocks may be used for directory information. Other Pertinent Information: System: Vax 11/780 running Vax/VMS 4.3 Please send mail to the following address: Bitnet: Sy$lee@Cuchem (First Choice) Arpanet: Oc.lee@cu20b.columbia.edu (Second Choice) Thanking all in advance, Tim
rimbold@dino.cpe.ulowell.edu (Rob Rimbold) (07/24/87)
***
The diskquota utility gets its information from the Quota.Sys file
on each disk. That file is updated periodically by the file system.
Reason number 1 why the dir/size/grand didn't match up to what
the Diskquota utility reported.
Reason number 2, is that the dir/size/grand reports only the *actual*
which amount of data in the file. The file may actually have allocated
more space than it is currently using. You may look at how much space it
has allocated with a Dir/size=All. Even then, I'm not entirely sure whether
or not that the size of the file headers are taken into account..
--
'Rob
Usenet: rimbold@hawk.cs.ulowell.edu
AT&T : (617) 452-5000 x2693
University of Lowell Productivity Center, Lowell MA.payne@watdcsu.UUCP (07/27/87)
In article <1729@dino.cpe.ulowell.edu> rimbold@dino.cpe.ulowell.edu (Rob Rimbold) writes: > >*** > >The diskquota utility gets its information from the Quota.Sys file >on each disk. That file is updated periodically by the file system. >Reason number 1 why the dir/size/grand didn't match up to what >the Diskquota utility reported. > >Reason number 2, is that the dir/size/grand reports only the *actual* >which amount of data in the file. The file may actually have allocated >more space than it is currently using. You may look at how much space it >has allocated with a Dir/size=All. Even then, I'm not entirely sure whether >or not that the size of the file headers are taken into account.. Not to mention file headers, which I believe are included in disk quotas, but not in DIR/SIZE. If you check a newly created user, with only a root directory to her/his name, you'll probably find that the directory is 3 blocks long, but disk quota reports 4 blocks used. The only thing missing is the file header of the directory file. It uses disk space, too. Jeeez, I sure hope this is the only answer like this. I sure wouldn't want to be part of a multiple contribution! Doug
"James_A._Gray.OsbuSouth"@XEROX.COM (07/28/87)
Original query: I have the following problem which is that there is a difference between diskquota and "dir /by_owner /size /grand". Using the diskquota facility, I see that a user has 48,976 blocks allocated to him but when I do a directory by ownership, there are only 42,578 blocks owned by him. Thus there is a difference of 6,398 unaccountable blocks. I used the rebuild option of the diskquota facility and that didn't change anything. Thus does anyone have suggestions or ideas where those blocks may be. I am aware that some blocks may be used for directory information. Response: Not only are the blocks that contain the directory charged to the user but the file header blocks are as well. There is at least one file header block for each file (and directory) that the user has; there will be more than one if the file header has been extended as would be common on a fragmented disk. Jim
hammond@cod.UUCP (John A. Hammond) (07/29/87)
VMS uses a minimum allocation size cluster (default = 3) when creating and extending files. If a file has only 1 block (512 bytes) in use then the directory size will show only 1 block in use even though the cluster_size is allocated. This can really byte (pun intended) if you have a user who creates 15000 1 block files on a disk that was set up with a cluster size of 16 to handle large data files more efficiently. Unfortunately the other 15 blocks allocated to each file were totally unavailable to the user (unless he extended the individual files which was not in his game plan) or anyone else. I got around the problem by moving the users files to a disk that had the default of 3 (still wasting a lot of space though).