disk partitioning

[Joseph Moran]

In article <497 at carina.noao.UUCP> grandi at noao.UUCP (Steve Grandi) writes:
>In article <385 at brueer.ee.brunel.ac.uk> andrew at me.brunel.ac.uk (Andrew Findlay) writes:
>>	[lots of stuff about /sys/vaxuba/uda.c having mapped-to sectors in]
>>	[the `c' partition and thus you have to be careful when copying]
>>	[the entire partition]
>For UDA-50 supported disks (i.e. RA81s) this is INCORRECT.

There are lots more cases where the bad sector information is not visible
to the user when copying `c' partitions.  At Sun, this is true on all of
our disk subsystems.

`SCSI' disks (ST506 and ESDI) let the controller handle forwarding bad
blocks.  The good side of this is that the UNIX driver should always
see a perfect disk.  The down side of this is that a bad sector which
shows up after the original format of the disk can only be "mapped out"
by using a disk utility to reformat the entire disk.  Another
consequence of this is that with the 4.2 fast file system which tries
to allocate file systems taking advantage of the geometry of the disk
can lose because a particular block might not be physically on the
cylinder group that the file system expects.  Thus smarter disk
subsystems can sometimes work against you.

`SMD' disks (e.g. A "normal" Fujitsu eagle) *CAN* let the controller
handle the bad block forwarding, but you have more control.  The
controller can avoid a bad block by "slipping" a sector.  When this
happens normally a logical sector is slipped to a spare sector on the
same track.  This way the data is on the same cylinder and track that
the file system expected.  Sun has been shipping SMD disks set up for
slip sectoring for a while now.

The other way to avoid a map block is to do traditional bad block
mapping.  This can be done by making the header on the bad sector
invalid.  Using a bad sector map which is read per disk, the UNIX
driver can figure out where to really get the data when it needs to.
Of course a mapped sector isn't great for a smart file system, but it
happens in such a small percentage of the cases, it normally isn't a
big deal.  But on all Sun disks, the `c' partition does not include the
bad sector map or the mapped-to blocks.  Thus on a Sun SMD disk,
copying the entire disk via dd of the `c' partition should never
be a problem.

Another important thing about Sun disks is that file partitions are
never hard wired in the driver (as they are on the Vax), they are read
in per disk.  The `c' partition is always a bit smaller than the actual
physical disk to allow for bad blocks, spare labels, and mapping info.
Having soft partitions avoids lots of disk partitioning problems that
you hear from users of systems which have the partition information
wired in the driver.  I'm sure there are lots of guru's out there that
know what I'm talking about.

Thus for all Sun disks, the `c' partition as seen by a user of UNIX
does not contain mapping information (other than the geometry of the
physical disk and partitioning information), and coping the default
`c' partition to another disk of the same type never destroys mapping
information.  In general it is a good idea to understand what is
going on before trying to copy the entire disk, or let someone
who does (like a support person from the manufacturer) do it for you.

I hope that this information helps sheds some more light on disk
issues.  My use of Sun disks as an example was just because I'm
familiar with them and I can use them as a counter example to
Vax UNIX usage of disks.

	Joseph Moran
	{ihnp4, decvax, seismo, decwrl, ...}!sun!mojo
	mojo at sun.COM (or mojo at sun.ARPA)