| From: Bertram Barth <bertram@ifib.uni-karlsruhe.de>
| 
| I don't know if it's possible to define partition boundaries in a 
| way that it maps to physical cylinder boundaries. If yes, then it
| would make sense to rewrite the /etc/disktab entries for most of the 
| MSCP disks. (IMHO these entries are slightly outdated in many ways 
| esp. concerning partition sizes/offsets and block/fragment sizes). 
| On the other hand now that /edlabel is available as an offline tool
| for creating disklabels, /etc/disktab is only used as a reference
| for physical/logical geometries?

All the times I laid out the labels on a wide variety of production
systems (Sun/Ultrix/OSF1) at my old job, I used the geometry to control
the partition sizes.

Heck, much of the time we had third party disks being added anyway - so
I'd hunt through our disktabs on various architectures for geometry info
- if none then I'd have to locate the vendor info.  I really hated
those zoned drives with varying sectors per track depending on the
cylinder.  Even with tools like scsiprobe and scsiinfo you'd have to
do some head scratching to come up with a consistent physical size even.

Anyway, I always made the partition boundaries on cylinder boundaries,
whether the cylinder boundary was just a figment of the old view of drives
or not. That way I'd not get all that crap about leaving out N blocks
with the newfs afterward.

I usually had some idea of the size I wanted for each partition, so I'd
divide that by the # sct/cyl to get a rough cyclinder count, make that
an integer, then multiply by # sct/cyl again to get my final # sct for
the partition.

You do want disktab for additional disks.  I have been using the TK50
image and I've got better things to do like wait for slow compiles than
to wait to load edlabel to also do additional drives 8-)