jdc@naucse.cse.nau.edu (John Campbell) (12/15/90)
Actually, I'm posting to help a friend. On the 4500 machines that
I help manage the sau7 directory is a reasonable size. On my
friends DN10000 the sau10 directory looks overly bloated. What's
the scoop (//carbon is the DN10000 machine):
# du //carbon/sau10
8 //carbon/sau10/cmd
84 //carbon/sau10/help
25204 //carbon/sau10/scan/cpu
43060 //carbon/sau10/scan/graphics
21156 //carbon/sau10/scan/memory
564 //carbon/sau10/scan/utility
90020 //carbon/sau10/scan
95976 //carbon/sau10
--
John Campbell jdc@naucse.cse.nau.edu
CAMPBELL@NAUVAX.bitnet
unix? Sure send me a dozen, all different colors.e07@nikhefh.nikhef.nl (Eric Wassenaar) (12/16/90)
In article <3067@naucse.cse.nau.edu>, jdc@naucse.cse.nau.edu (John Campbell) writes: > friends DN10000 the sau10 directory looks overly bloated. What's > the scoop (//carbon is the DN10000 machine): > # du //carbon/sau10 ... > 90020 //carbon/sau10/scan > 95976 //carbon/sau10 Most files in the scan directory are 'rec' files. The size reported by 'du' is a factor 4 too big for such files. Try /com/lst and you will see the real size. Eric Wassenaar -- Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands Phone: +31 20 592 0412, Home: +31 20 909449, Telefax: +31 20 592 5155 Internet: e07@nikhef.nl
vinoski@apollo.HP.COM (Stephen Vinoski) (12/16/90)
In article <3067@naucse.cse.nau.edu> jdc@naucse.cse.nau.edu (John Campbell) writes: >Actually, I'm posting to help a friend. On the 4500 machines that >I help manage the sau7 directory is a reasonable size. On my >friends DN10000 the sau10 directory looks overly bloated. What's >the scoop (//carbon is the DN10000 machine): > ># du //carbon/sau10 >8 //carbon/sau10/cmd >84 //carbon/sau10/help >25204 //carbon/sau10/scan/cpu >43060 //carbon/sau10/scan/graphics >21156 //carbon/sau10/scan/memory >564 //carbon/sau10/scan/utility >90020 //carbon/sau10/scan >95976 //carbon/sau10 As you can see most of the space is being taken up by the /sau10/scan directory. That directory mostly contains databases used by the offline SCATMAN (which stands for "SCAn Test MANager") utility for testing the various XBUS boards. The databases are compressed, to some extent. Unfortunately, SCATMAN has only 36k of service processor RAM to operate within, and it must work through all these databases in order to fully test the machine, so there was no space available for a fancy decompression algorithm. For what it's worth, the SCATMAN diagnostics achieve a fault coverage well above 90% for each of the XBUS boards, in a run time of only 20 minutes or less per board. From a testability and diagnosis point of view, the complexity of each board is staggering. Traditional DEX diagnostics would have had run times of hours and would still have not even approached this high level of fault coverage. Simply put, we traded disk space for the ability to ensure the correctness of the XBUS boards. If you've had trouble with an XBUS board that the diagnostics didn't catch, I'd like to hear about it. If your DN10000 does not have the XBUS graphics board, and you never plan to get one, you can delete the /sau10/scan/graphics directory. If you have several DN10000s on the same ring, I suppose you could delete the /sau10/scan directory from all but one of them, then boot diskless off the one if it ever becomes necessary to run SCATMAN diagnostics. Hope this explanation helps. If you have any further questions about this, feel free to send me email. -steve | Steve Vinoski (508)256-6600 x5904 | Internet: vinoski@apollo.hp.com | | Testability and Diagnostics | UUCP: ...mit-eddie!apollo!vinoski| | HP Apollo Division, Chelmsford, MA 01824 | ...uw-beaver!apollo!vinoski|
rees@pisa.ifs.umich.edu (Jim Rees) (12/18/90)
In article <1080@nikhefh.nikhef.nl>, e07@nikhefh.nikhef.nl (Eric Wassenaar) writes:
Most files in the scan directory are 'rec' files.
The size reported by 'du' is a factor 4 too big for such files.
Try /com/lst and you will see the real size.
Actually, it's worse than that. They're off by 16, due to a multiply that
should have been a divide. So that 100 Meg directory is really only 6 Meg.rees@pisa.ifs.umich.edu (Jim Rees) (12/18/90)
In article <4ea73223.1bc5b@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu (Jim Rees) writes:
Actually, it's worse than that. They're off by 16, due to a multiply that
should have been a divide. So that 100 Meg directory is really only 6 Meg.
Sorry, my mistake. For rec files it is only a factor of 4. 25 instead of 100.