OT: redhat

[Bill Vermillion]

Brian K. White, the prominent pundit, on Sat, Nov 06 04:15  while half 
mumbling half-witicized: 

> Bill Vermillion wrote:
> >On or about Fri, Nov 05 20:16 , while attempting a Zarathustra
> >emulation Fairlight thus spake:

...

> >I just don't see the sense in having a single / on a 40GB or larger
> >disk, which is what I'm seeing recommended by some people in some
> >of the newsgroups.

> >I've seen more than one system with / corrupted while everyting
> >else is intact.  ...

> Some of the arguments for them are starting to sound like
> recommending keeping all fs's under 2 gigs so that in a pinch
> they can be archived into files or under 700 megs so that they
> can fit onto cd's.

I saw nothing like that - or anything that came close to that idea.
I just checked one of my web-servers.

/ is 123MB, /var is 123MB, /usr is 115Gb and /usr2 is about 4GB.
/usr2 is a scratch area so I can do things that won't polute the
main filespace.

In today's world if you kept your file systems under 2GB you'd
probably run out of space for filesystems in most of the modern
Unix systems, and run out of logic driver letters in the MS world.

> They do work as an effective diagnostic alert. "/ filled up,
> something must be out of whack..." then you find it and some
> mail or print spool problem gets fixed.

IMO mail or print don't belong under / - but an another file
system.  Any part of an OS which could grow out of control needs to
be made sure never to be on /.   That's just good planning.

And / will never really run out of space on systems that prevent
anyone except root from using all the space.  That is something
lacking in some OS distributions.

> I'd much rather have a less drastic form of notification and
> have the problem go unnoticed longer and the box keeps running
> and gets noticed gradually because the backups seem to be
> taking way too long or one of my cron jobs sends me an email
> when dfspace reaches a certain threshhold value or somthing,
> and the box keeps running and oh yeah, the box keeps running.

If you have systems that you worry about you should have email
notification that you construct to monitor things.

> One reason I do find to limit a fs to less than the size of the
> disk is if the fs only performs well below a certain size.

> The possibility hadn't occured to me until last year when sco
> came out with an update to htfs so that it (supposedly) no
> longer has a performance dive when the fs is larger than about
> 50 gigs. I had very few sco fs's that were over 36 gigs at that
> time so I never knew there was that issue but now I do, and
> now it's supposedly not a problem any more but the possibility
> still remains just probably at higher numbers and in any event
> as something to keep in mind for any fs / any os.

Note true fo 'any fs / any os' - but true for SCO.  Part of the SCO
problems IMO is that it started life as a SysV3 and just grew and
grew.  The SCO customer base is one that like to hold onto their
OSes as long as possible so keeping OSR5 in the product line might
have been a good business decisions for them.  But all other
commercial Unix vendors had moved to a SysV4 by 1995.  And within
a few years of that most of the other independant [eg not
distributed by a hardware company with their hardware] Unix vendors
had disappeared, leaving SCO alone as the only commercial
independant Unix vendor for the Intel platform.

Bill

-- 
Bill Vermillion - bv @ wjv . com