JARRELLRA@VTMATH.BITNET (Ronald A. Jarrell) (02/08/86)
There's a well known problem (at least at DEC-U.S....) with 4.N and quota leakage.. There's a few bugs in the < 4.2 XQP, and still some in the 4.2 one... I don't recommend running the vanilla 4.0 or 4.1 XQP's at all, DEC has a special SPR response patch that gives you what they called the 4.1++ system (a almost 4.2 XQP), and I have unconfirmed reports of a similar deal for 4.2 systems, that gives them the more or less frozen (at least quite slushy) 4.3 XQP.. Course, I'm starting to get tired of testing DEC's operating systems a piece at a time.. I'd like to not need parts of 4.2 until I want to install the whole kit, but that's been the story of 4.N.. -Ron Jarrell Va Tech Computing Center
BMW6957@TAMCHEM.BITNET.UUCP (01/21/87)
Had a little problem sending this first time, I'll try it again -- BW >On our VAX system I have noticed that the disk quota information >I get, whitin DISKQUOTA, whit: > >SHOW [*,*] > >disagree whit DIRECTORY ( or DIRECTORY/BY_OWNER ) totals. >For UIC's like [1,1] the difference is very high ( for the UIC [1,1] in >particular the DIRECTORY reports a total block allocated much greater >than the DISKQUOTA number; other UIC's report a reverse situation ). > >Our users frequently can't work due to DISKQUOTA exeeded. The values given by DISKQUOTA include blocks allocated to the file header in [0,0]INDEXF.SYS as well as the allocated size of the files. DIRECTORY shows the allocated size and size used (if /SIZE=ALL is specified), but not the header blocks allocated. The numbers obtained by DISKQUOTA will never agree with those from DIRECTORY since each file and directory has at least one header block (it may have more than one depending on file size, contiguity options, and disk fragmentation). Often the two values are not even close as you observed. However the size DISKQUOTA gives should always be greater than that shown by DIRECTORY. That leads to the next problem: The quota file can get out-of-sync with the file structure, especially if you've had a system crash (and who hasn't had one of these at some time?). There are two ways to bring it back in line--use the REBUILD command under DISKQUOTA, or use the VMS command ANALYZE/DISK/REPAIR. ANALYZE should only be used if there is no disk activity, whereas DISKQUOTA's REBUILD command can be done on-line. If at all possible, I would suggest using the ANALYZE command, as that will find and correct many other problems such as lost files (Lost files are files that exist on the disk, but their directory pointers have been removed. Lost files are still counted against the owner's quota) and files marked for delete (Files that are found "marked for delete" were never actually deleted, e.g. a crash occurred preventing complete deletion, they still exist and still occupy quota). Be absolutely certain to read the manual about ANALYZE/DISK (Verify utility) and the possible ramifications of the /REPAIR qualifier ESPECIALLY if you intend to do this on your system disk! Make sure you have a current backup. You may also want to do a "dry run" (i.e. ANALYZE/DISK without the repair qualifier) just to see how bad the file structure really is. You may consider doing this periodically to keep the file structures cleaned up (I do it whenever we've had a scheduled shutdown, before I let users back on the system). Hope that helps, Brad Wilson