Disk Partitioning, ULTRIX

[Alan's Home for Wayward Notes File.]

In article <2615 at canisius.UUCP>, pavlov at canisius.UUCP (Greg Pavlov) writes:
> 
>   [ Quoteing from the DECstation 3100 /etc/disktab... ]
> 
>   "...all disks have no defaults for the 'h' partition.  The strategy here
>    is that 'a' always has the same amount for all disks.  The 'b' partition
>    is four times 'a' while 'c' is always the entire disk.  The sum of 'd','e',
>    and 'f' is equal to 'g' which is everything else."
> 
>  Ok, we pay attention to the "rule" for the 'c' partition.  But none of the
>  rest make any sense to us, at least most of the time.  Where does these algo-
>  rithms come from ?  

	The subset of disks in that disktab is very small being all
	the SCSI disks we we had available with the DECstation was
	announced.  If you look at the disktab on VAX you will nearly
	as many different styles of partitioning as there are disks.
	I would guess that the engineers that setup these partitions
	tried to get some consistancy.  The choice of size for the
	A partition was probably one which would comfortably fix the
	root file system for the RISC systems.  

	Making B four times the size of A gives a good safe size for 
	the page and swap.  Having G be the rest of the disk and making 
	D, E and F be sub-partitions of G is easy to remember and cal-	
	culate.  For the RZ55 at least D, E and F are one third of G.

> What is in ULTRIX that penalizes ignoring them ?

	/etc/disktab is the default.  If you don't like the defaults
	we provide chpt to give the disk it's own partition table
	and editors so that you can have disktab reflect reality.  As
	long as you live by the restrictions of chpt(8) you probably
	won't have any problems.  The biggest mistake that people make
	is accidently having two partition overlap or paging over the
	partition table.

	If you find a partitioning that works better, go ahead and
	use it.  If you find some real performance benefit from it,
	let us know.
	long as you 
> 
>   greg pavlov, fstrf, amherst, ny


-- 
Alan Rollow				alan at nabeth.enet.dec.com