Disk partition size vs. Performance

Ed Hew edhew at xenitec.uucp
Thu Jul 20 16:27:56 AEST 1989


In article <774 at lilink.UUCP> mikej at lilink.UUCP (Michael R. Johnston) writes:
>For some time now I've heard from various people that it is unwise to
>NOT partition large Xenix file systems. For example, we typically install
>systems with 103 meg hard drives in our franchise offices. To simplify the
>installation I normally only create one large filesystem. I suspect that
>there are several advantages to partitioning that are not apparently
>obvious. My main intent is to keep the installations as simple as possible.

The only reason I can think of why someone might want to have multiple
xenix partitions would be to enable you to boot selective different
xenix systems, but perhaps someone else can provide other reasons.

I will make the assumption that you don't mean multiple partitions, but
rather multiple filesystems.

>My questions are:
>
>	1- What are the advantages of using multiple smaller partitions?

(assuming we mean fs's) You can limit problems with specific parts of
your system "overflowing" and grinding a single fs system to a halt.

For example, I have the following here:

Mount Dir   Filesystem  blocks	  used	  free	% used	 iused	ifree	%iused
/           /dev/root   140000	112366	 27634	   80%	 5659	11829	   32%
/src        /dev/src     71742	 64330	  7412	   90%	 2664	 6296	   30%
/usr/spool/ /dev/news   140000	111444	 28556	   80%	18885	 6107	   76%
/usr/spool/ /dev/uucp    40000	 12162	 27838	   30%	  204	 7796	    3%

so, if my news filesystem overflows, it doesn't eat my root filesystem
and bring the system to a semi-crashing halt for lack of disk space.
So, I loose some news, oh well, I would have anyhow, but the system
as a whole stays alive and I can rectify things relatively easily.

Another simple reason is that of course it makes backups much easier.
My root fs changes can usually fit onto a floppy monthly, whereas
(if I followed my own advice after buying a _still_larger_ drive) my
user files (/dev/u which I should have) would (and does) change by the
minute.

Again, news is nice, but I don't back it up daily, so having it in it's
own fs makes this easy.  Same with /dev/uucp (which is mounted on
/usr/spool/uucp ).  ..... you get the picture.....

Actually, I have one *more* fs than is shown above, but I only mount
it when I need it, so it's effectively hidden.  I know it lives and
can mount it, nobody else knows about it.  :-)  Even if my users did
(from reading this article perhaps), it's not user mountable.  This
could be a useful security precaution for sensitive data.

I'm sure there are more reasons, those are the ones which come to mind
at the moment.

>	2- If using smaller partitions is advantageous, what is the rule
>	   of thumb (if any) that one uses to determine partition size.

Simply estimate what the contents of the proposed fs require, tempered with
the physically available space overall, and make your filesystems accordingly.
Each site is different in this respect.  At the same time, decide whether
the default number of inodes created are appropriate to your use of that fs.

>For example, we typically install
>systems with 103 meg hard drives in our franchise offices. To simplify the
>installation I normally only create one large filesystem. I suspect that
>there are several advantages to partitioning that are not apparently
>obvious. My main intent is to keep the installations as simple as possible.

You'll have to decide whether the advantages are sufficient for your 103meg
sites.  Typically for storage of that nature, I would make a root fs and
a /u fs and leave it at that, as you're not likely to be running things
like news on it or feeding a number of uucp sites.

		--ed		{edhew at xenitec.uucp}
>Many thanks.
>Michael R. Johnston, System Administrator             rutgers!lilink!mikej

  Ed. A. Hew             Technical Trainer             Xeni/Con Corporation
  work:  edhew at xenicon.uucp	 -or-	 ..!{uunet!}utai!lsuc!xenicon!edhew
  home:	 edhew at egvideo.uucp	 -or-	   ..!{uunet!}watmath!egvideo!edhew
  home:	 changing to:  edhew at xenitec.uucp     [but be patient for new maps]
  # I haven't lost my mind, it's backed up on floppy around here somewhere!



More information about the Comp.unix.xenix mailing list