big versus small disk partitions

dan at rna.UUCP dan at rna.UUCP
Sat Feb 11 10:56:56 AEST 1984


	I would tend to favor your suggestion of 3*100Mb partitions on the
Eagle. In fact that is exactly what I did. I think a major reason Berkeley
went with the large partitions is to standardize disk partitions across
different drives with a consistant partition rules.  We only have Eagles on
our VAXes and I wanted to optimize our daily operations with the disks rather
than once in a year transfers between different drives.
	In practice, we have found it very useful to have very few disk
partition sizes so that raw copies of filesystems between partitions were
possible. I have filled up our Eagles with so much source that it becomes very
nice to swap out a little used source partition from time to time with raw
copying. Here is our current partition scheme, we run 4.2BSD on the Eagle...

		cyl	sectors
	hp?a	17	16320		root
	hp?b	34	32640		swap
	hp?c	842	808320		entire disk
	hp?d	17	16320		/tmp
	hp?e	17	16320		/usr/spool
	hp?f	252	241920		/usr
	hp?g	252	241920		/usr1	users
	hp?h	252	241920		/src	source

	The distribute root filesystem, hp?a remains the same (15884 sectors),
but the disk partition table has been rounded to whole cylinders to make dd and
fsck happy.
	There are only two partition sizes used for filesystems. Moving things
around with dd is simple.
	hp[abdefgh] map the whole disk minus one cylinder. I chose to hide the
last cylinder where the bad sector table resides from any filesystem partition
so it will never get clobbered by mistake. I lose a few hundred sectors, .1%
	Filesystems /tmp and /usr/spool live by themselves in small partitions.
Corruption cannot spread.
	The larger size, 241920, fits comfortably on a single 6250bpi tape. You
can add a small guy on the tape's end.
	With 4.2BSD, you can decide on filesystem blocking parameters on a per
filesystem basis. I just like the idea of file usage, performance and problems
contained within a stereotyped partition.
	Comments?

						Cheers,
						Dan Ts'o
						...cmcl2!rna!dan



More information about the Comp.unix.wizards mailing list