Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!sri-unix!hplabs!felix!peregrine!ccicpg!gershon
From: gershon@ccicpg.UUCP ( Gershon Shamay)
Newsgroups: net.unix-wizards
Subject: Re: Disk partitioning -- some thoughts
Message-ID: <132@ccicpg.UUCP>
Date: Wed, 15-Oct-86 01:10:33 EDT
Article-I.D.: ccicpg.132
Posted: Wed Oct 15 01:10:33 1986
Date-Received: Sat, 18-Oct-86 00:37:53 EDT
References: <88@houligan.UUCP>
Organization: CCI CPG, Irvine CA
Lines: 57

Just to add some spices to the discussion. At CCI we implemented what we
call a 'dynamic partitioning' scheme (on CCI's 6/32 machines).
The implementation is simple. The partition info is kept on the
drive itself, in the first block (at least 1k) which is not used
for any bootstrap program. The table contains information for each
partition, like where it begins, how big it is and even type (this way
the same drive can have BSD or AT&T or swap or... type of partitions,
mixed and independent of each other). There's also drive-specific
information like size ( # of cylinders, # of heads, etc). Plus data like
RPM, sector size and so on - the delight of newfs and the like.
Most of this table is put on the drive by the formatter program.
Now for the fun part of it.
1) A special user-level program allows root to change any data, thus
	effectively re-partitioning the drive. Anyone can view the table.
2) A special ioctl to the disk driver allows root to WRITE this table.
	Any other writes to this area are quietly ignored.
	That's how dd's and the like CAN"T ruin the drive info.
	You even get an error message if something is currently
	mounted on this drive.
3) The special program is the only one that uses this ioctl.
4) When Unix comes up, the disk driver reads the table off the drive.
	From here on, it knows everything it needs about it. No need
	to re-compile the kernel or define ANYTHING about drives. Any
	new drive type is automatically supported by the same kernel.
5) The same ioctl will happily read the table for you. Programs
	like newfs (or mkfs) etc just use the library routines to read
	disk info. We changed the library to ask the driver first and then
	go to /etc/disktab. So the on-drive table has precedence over
	any nonsense one may have in disktab. If there's no table
	on the drive (can happen, backward compatibility, etc) THEN
	/etc/disktab is used.
6) The on-drive table keeps a nickname you assign to he drive
	(a string of chars). At bootstrap time, the OS prints on
	the console all the drive types it finds connected, including
	the nicknames (if any). Handy for people who forget.

So far, this scheme is working great. We got rid once and for all of the
hard-wired tables in the kernel and the need to send out a new version
of Uni*x to support new drive types. The same scheme should work fine
for removable packs, too.

The only 'pure' problem we had to consider with this scheme was point
#2 above (ignoring writes to the first block). AHA ! There goes the
semantic of the raw disk device. True to a point. In real life, we
considered it not to be a problem. All the writes to the raw disk at
block #0 were found to be 'dd' types where one wants to keep a copy
of an 'a' partition for disasters. Now if one does that, he should
better have both partitions being the same size. On top of which,
he usually doesn't want to ruin the rest of the destination
drive anyway. Bottom line - even in this case there's no reason
to wipe out the on-drive table. And writes to the block device
never go to block #0 (reserved for bootstrap, courtesy of Uni*x 
history).

					Gershon Shamay
						CCI
					Computer Products Group