[comp.sys.apollo] Why is Domain OS so big?

rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/08/89)

I bought my DN10000 with the 300megabyte drive, figuring that this would
do me for a long time, until I managed to set up some optical secondary
storage, or until the price of big, fast disks came down.  Allright, so
I am used to my various Macintosh setups, where I have labored for years
without filling up my 80 meg of disk storage.  Thought if I ever got
300 meg, I'da died an gone to heaven.
    Well, nobody expects Unix to be as compact as the Mac os, which
after all doesn't do as much as Unix (though in some ways it does a lot
more.  Wish I had that 256K toolbox in rom on the 10000!).  But Domain
OS is a real disk hog.  I installed BSD_medium, and found that the
OS files take up an amount pushing 150 megabytes (even after deleting
the games directory)--and yes, I did install using hard links.  With the
"medium" installation you don't even really get all the Unix you need, 
e.g. you don't get support for Unix "plot" under DM.  And now I find that
with 10.2, in order to get the X developer tools, I will need to do
a "large" installation. This means I will really need to spring mucho
$$$ to get an expensive Apollo 700MB disk to stay in business.
    Now, I don't want to get into the tired "apollo vs. sun" thing.  I've
had enough with the interminable and unproductive "mac vs ibm" thing (but
alright, since you asked, since you twisted my arm, yes the mac is better
than ibm and apollo is generally better than Sun, except that the 
sparcstation is a great little machine at a great price and I wish
Apollo had a PrismStation, but no let's not start a thread on this,
it was just because I heard you insisting to know ...:)).  But the 
fact is people have Sun 3/50's with 70MB scsi disks running SunOS
as stand-alone systems (i.e. no links to file servers anywhere), and
still have room left over for their data files.
    I think it is probably easier for me to get more disk space than
to hack around with custom installations (I am the prime user and 
sysadmin all in one of this 10000, and tend to think of it as a kind
of expensive personal computer). For me, I like minst just fine.  
But is there some intrinsic reason why the OS on the DN10000 has to
be so big?  What am I getting for all that space?  It is a real nuisance,
because not only do you need more disk space, but you have to spend
time backing it all up.  Does anybody have any bright ideas as to
what I could delete to free up significant amounts of space?  What
is all that stuff in the sau10 directory for?  Is all of it really ]
needed?  
    What is really needed is a minst script tailored for an installation
such as mine, which is strictly a single-node operation.  Something that
gives you what you need without all the fluff.  Failing that, Apollo
ought to offer a cheaper line of 700MB drives.  I'd much rather be
spending $13000 for a second processor than for another disk drive.
 

krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (12/08/89)

Hmm ... something doesn't sound right here ... I've loaded the "large"
installation of Aegis plus BSD onto my DN560 with a 150MB disk. Granted,
there was only 6MB left after booting and starting *all* the servers
(rgyd, llbd, glbd, sendmail, tcpd, and 3 or 4 of my own). This was for
SR10.2, including the X windows load with hard links.

I can think of the following things to check:

1) MINST seems to load all of the M68K sau directories from the
   tape into the /install directory even though I only asked for
   one or two of the /sau directories. It may be doing something
    similar for the DN10000.

2) While helping someone else here at MIT who has a DN10000 load
   software, I noticed that the /sau10 directory contains a couple
   of subdirectories full of microcode and diagnostic code. A lot
   of the code is for the 40 and 80 plane graphics subsystem. One
   or the other set (or both, if you have the regular 8-plane
   graphics system) can be removed from the system.

3) When we loaded SR10.1p onto this person's DN10K, not everything
   that was supposed to be hard linked actually got linked. Some of
   the stuff was, in fact, copies rather than links. I don't remember
   which directories were involved, off hand, but you might poke
   around your system. We loaded both Aegis and BSD onto his system
   (with a 350MB disk like yours) and had 180MB left over. If your
   just loading BSD, you should have more like 200MB left.

4) Remember that under SR10.1p, every process running on the system
   takes up 5MB of disk space for virtual memory for the stack 
   (0.5MB on M68K machines). If you have 10 servers running, which
   is not unusual, you have 50MB of disk space tied up for stack
   space. SR10.2 fixes this. Stack space is allocated dynamically
   as it is used.

Elminating the extra /sau directories from my DN560 saved me about
20-25MB. If I remember correctly, the 40/80 plane graphics code and
diagnostics were about 10 or 20MB, and the stuff that failed to get
hard linked was another 20MB or so.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)

vinoski@apollo.HP.COM (Stephen Vinoski) (12/10/89)

In article <6627@tank.uchicago.edu> rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) writes:
>                         Does anybody have any bright ideas as to
>what I could delete to free up significant amounts of space?  What
>is all that stuff in the sau10 directory for?  Is all of it really ]
>needed?  

Most of the files in the /sau10 directory and subdirectories have to do with
diagnostics.  Apollo machines usually only have diagnostics which run under
the Diagnostic EXecutive (DEX), but due to the enormous complexity of testing a
machine like the DN10000, we chose to use scan testing techniques to provide
high fault coverage and good fault isolation.  Scan tests execute quickly, but
require large amounts of input data and expected output data.  Most of the files
in the /sau10/scan directory are scan test data files which are used by the scan
diagnostic executive (called the SCAn Test MANager, or SCATMAN) to test the
machine. These data files are highly compressed but some of them are still
pretty large.

One good way to free up some disk space on a DN10000 which does not have 
Visualization System graphics (an X-Bus graphics board) installed would be to
delete the /sau10/scan/graphics directory - that will give you ~10 megabytes
back.  HOWEVER, I strongly suggest that you avoid deleting any of the OTHER
/sau10/scan subdirectories

         /sau10/scan/cpu
         /sau10/scan/memory
         /sau10/scan/utility

if your DN10000 is a stand-alone system; without them, SCATMAN will be unable to
test and diagnose the machine.  Note that the DEX diagnostics were designed to
be run only after the SCATMAN tests pass, since those diagnostics require
hardware which is verified by SCATMAN.  If you have multiple DN10000's on a
network, only one of them really needs to have the SCATMAN and DEX diagnostics
installed, and the rest can be tested by booting the diagnostics from the disk
on that node.

Of course, as soon as you purchase and install the X-Bus graphics board, you
will have to reinstall that /sau10/scan/graphics directory...      ;-)

Hope this helps.


-steve
| Steve Vinoski       | Hewlett-Packard Apollo Div. | ARPA: vinoski@apollo.com |
| (508)256-6600 x5904 | Chelmsford, MA    01824     | UUCP: ...!apollo!vinoski |
| "My second wife isn't even born yet."                                        |

ross@cancol.oz (Ross Johnson) (12/11/89)

In article <8912081415.AA12414@richter.mit.edu>, krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) writes:
> Hmm ... something doesn't sound right here ... I've loaded the "large"
> 3) When we loaded SR10.1p onto this person's DN10K, not everything
>    that was supposed to be hard linked actually got linked. Some of
>    the stuff was, in fact, copies rather than links. I don't remember
>    which directories were involved, off hand, but you might poke
>    around your system. We loaded both Aegis and BSD onto his system
>
This happened to me too (SR10.1p). I think it was most of /bsd4.3/usr/bin.
Our 10000 originally came preloaded, but has since been invol'ed and reloaded
off tape. I mention that because I asked the local Apollo engineer to check
his 10000 which he found was ok. I presume his came preloaded too.

> 4) Remember that under SR10.1p, every process running on the system
>    takes up 5MB of disk space for virtual memory for the stack 
>    (0.5MB on M68K machines). If you have 10 servers running, which
>
????
Unless 'df' is lying to me ('du' does!), each process only?! grabs 500k 
(SR10.1p) - same as for the m68k machines. That is, as a minimum.

+----------------------+---+
| Ross Johnson	       |:-)|  ACSnet: ross@cancol.oz.au
| Info. Sciences & Eng.|___|  ARPA:   ross%cancol.oz.au@uunet.uu.net
| University of Canberra   |  UUCP:   {uunet,ukc}!munnari!cancol.oz.au!ross
| P.O. Box 1               |  CSNET:  ross%cancol.oz@australia
| Belconnen  A.C.T. 2616   |  JANET:  ross%au.oz.cancol@EAN-RELAY
| AUSTRALIA                |  BITNET: ross%cancol.oz.au@relay.cs.net
+--------------------------+

lori@hacgate.UUCP (Lori Barfield) (12/12/89)

Discussing OS disk hogging, David Krowitz writes:
>> 4) Remember that under SR10.1p, every process running on the system
>>    takes up 5MB of disk space for virtual memory for the stack 
>>    (0.5MB on M68K machines). [...]

In article <267@cancol.oz> ross@cancol.oz (Ross Johnson) writes:
>Unless 'df' is lying to me ('du' does!), each process only?! grabs 500k 
>(SR10.1p) - same as for the m68k machines. That is, as a minimum.

I remember hearing that firing up a diskless node under SR10 soaks up
6MB of disk, a lot of it for swap.  Perhaps this is related.  It
certainly is a problem, although not exclusive to the 10k.


...lori

(an SR10 wanna-be anyway)

rtp1@tank.uchicago.edu (raymond thomas pierrehumbert) (12/12/89)

I have received many interesting comments on this, and provide a
digestion of some of the more critical ones:

(1)  My size estimates seem large. 
This is true.  I did a crude estimate originally, based on df, and
came up with the almost 150mb figure. I did a better estimate by
taking a du, and subtracting the "install" directory and my "users"
directory,which is where all our own stuff resides (except for
Kermit, C and Fortran compilers).  Result is 120MB, not 150.

(2) The stuff in sau10 is sophisticated scan diagnostics, which
is large by its very nature.  
Well, at least it's nice to know what I'm getting.  Certainly,
I'm all for good hardware diagnostics. Downtime, and MyTime are
a lot more expensive than disk space

(3) You could free up some space in sau10 by eliminating the scan/graphics
diagnostics for 40 and 80 plane controllers, if you don't have them.
The rest of the stuff is really needed.

(4)  Comparing the Sun 3/50's with Prism was apples and oranges.
Point well taken, Indeed, the 3/50's were running an old Sun OS,
and if they ever upgrade, they'll be in trouble.  Further, 
object code for RISC architectures like Prism is always larger
than for CISC architectures.  Asking around, I have found that the
OS for Sun 4's, Sparcs, and for SG Iris's are not much smaller than
10.1p

So, all seems to be right with the world-- except I wish disk space
were cheaper.  Seems we are perhaps beset by the "creeping featurism"
that the Unix gods used to inveigh against.  I do wonder sometime
about just what has happened to Unix.  I need my DN10000, and I need
my MacII's, but the fact is that the 1MB operating system on the MacII
does about 80% of what an OS ought to, and am not a little disconcerted
that getting the remaining 20% takes 119MB.  This, of course, is not
an Apollo-Specific comment.

krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (12/12/89)

Yeah, firing up a diskless node would start about 6 or 7 
processes on the diskless node. Under SR10.1, each process
had 500Kb of stack space plus whatever else they used in
the way of common storage, static arrays, and the like.
It's better under SR10.2. The stack space allocation is
done differently.


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)

ALBRECHT@INTELLICORP.COM (Steve Albrecht) (12/14/89)

RE: Why is DOMAIN/OS so big?

I was able to install a full BSD plus links to SYS5 and AEGIS on another
node in 49MB.  I happily have 98MB free on my little 160MB hard disk.

I do not know why/if OS 10.1 requires lots more space on a DN10000 (I did
this on a DN3500).

(::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::)
) Steve Albrecht - IntelliCorp, Inc. - Knowledge Systems Product Development (
( "Opinions expressed here are my own, if anyone's, and not my employer's."  )
) DDS   albrecht@intellicorp.com         :     COMPUSERVE  73657,1342        (
( UUCP  ...!sun!intellicorp.com!albrecht :     public bbs  (415)969-5643     )
)   or  ...!sun!icmv!albrecht            :                "c"omment to sysop (
(::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::)
-------