>> Note that each partition must be a complete cylinder on SPARC.
>
>Sigh.  This is not true - or at least, if it is, it's gratuitous and
>comparatively recent.

(sigh)  I guess I will have to *parse* my words more precisely.  :>
And, I guess the disklabel(8) man page will need to be revised:
"On the sparc... the size of each partition must be a multiple of
the number of sectors per cylinder..."

I've found this a reasonably safe practice to follow when moving
among different OS's.  Another "legacy" issue...

>The issue is in the Sun-compatible disklabel.  It stores partition
>beginnings in cylinders, and hence has no way to represent a partition
>that does not begin on a cylinder boundary.
>
>Now, the Sun-compatible label is needed if the disk is a boot disk
>(since the ROMs must be able to understand it) or if it's to be shared
>with other OSes that don't understand BSD labels.  While it's not truly
>needed except for those cases, I think the kernel always writes it
>anyway (it certainly used to) and hence rejects any label that cannot
>be represented in the Sun-compatible format.
>
>However, there has never been any requirement that partitions *end* on
>cylinder boundaries.  If they don't, other than at the end of the disk,
>there will be a small amount of unavoidably wasted space, but that's
>about it.

And, regardless, newfs(8) can opt to "waste" a bit in the last cylinder
of the partition, anyway.

>> So, consult your disk geometry to figure out EXACTLY how many sectors
>> per cylinder on your drive.
>
>This betrays another (apparent) misconception.
>
>On any even vaguely modern disk (basically, any disk that's likely to
>be still in service), the number of sectors per track varies depending
>on the cylinder number, in an attempt to keep bits-per-area at least

Yes, "Zone Density Recording".  Though SCSI terms each "region of
constant sectors per track" (:-/)  a "notch".  There, the term "zone" is
an (arbitrary) number of cylinders to which an (arbitrary) number
of replacement sectors are allocated.  (sigh)  Let's confuse things
even more!  :>

>roughly constant across the disk.  This means that there simply is no
>single sectors/cylinder number that matches reality.

The fixed CHS geometry idea is a throwback to days when sector translation
was "hardwired" in the drive's control logic.

Modern drives still report a (bogus) "geometry" to satisfy this model.  One
might suspect that the number of heads and/or tracks *could* reflect the
real geometry of those aspects of the drive (i.e. you can *count* the
number of platters in a particular drive!) yet there is no need for the
figures reported to coincide with "reality"; the controller within the
drive can play whatever games it wants with translation -- though there
are some "conventions" that are adopted for LBA that intend for the
*relative* locations of sectors to be "predicted" -- e.g., sector #2 will be
"near" sector #1 (note that it is conceivable that the drive could
translate any damn way it choses!  :>)... -- and "the first sector" of the
disk must remain in the same place regardless of the geometry
*selected* for the drive (e.g., [E]IDE).

I've always found it amusing that the IDE IDENTIFY is used to tell
the *drive* what it's geometry is (instead of the drive telling the *host*).
Note that even SCSI -- with it's increased capacity for passing
information back to the host -- still maintains the illusion of a
single, homogenous disk geometry.  The "Notch Page" provides
a mechanism to report more details about the size and configuration
of each "notch" but support for this is not required by the standard.

>So, how does this work with the above about partitions beginning on
>cylinder boundaries?  Well, the `cylinder boundaries' on which
>partitions must begin are not actual cylinder boundaries on the disk,
>but rather multiples of the (sec/trk) * (trk/cyl) product, where those
>two numbers are the ones in the disklabel.

The *BSD* disklabel, in this case.  Note that there is an extra layer
of requirements for i386 architecture (off topic).

>Note that I did not say "the ones the disk reports".  The disklabel
>values default to the ones reported by the drive, but you can put

Again, the *BSD* disklabel.  And the i386 "BIOS" numbers make
an even bigger mess of it all.

>whatever you please in for sec/trk and trk/cyl numbers, and the
>`cylinder' boundaries you have to begin partitions on will be multiples

Yes.   factor(1) is your friend... :>

Also, I think that the boot loader for shared drives requires
the first complete *track* to be setaside -- i.e. the useable partition
begins at the start of the *second* track -- for compatibility with
other OS's (?).   At least, this *had* been the case in the past...
("Once burned, forever leary...")

>of their product.  (Well, there is a restriction; each number must fit
>in 16 bits.)

And, on i386 you have other restrictions imposed by the BIOS/"MBR"
that limit the choices you have for fabricating an *arbitrary* disk
geometry (at least if you want the drive to be shared/bootable!)

[Hmmm... note to self:  check if the IDE geometry is *reset* during
the boot sequence...]

>It may work to simply set sec/trk=trk/cyl=1 in the label and put
>partitions anywhere.  Some values in the Sun-style label are only 16
>bits wide, but the starting cylinder numbers for partitions are not
>among them.  (I think NetBSD doesn't care about any relevant values
>that are only 16 bits, perhaps most notably the total cylinder counts;
>you may have trouble if you try to share the disk with Sun OSes.)  I
>haven't tried it myself, but I can't see any reason offhand why it
>wouldn't work.
>
>Personally, what I generally do is ignore the geometry reported by the
>drive and set trk/cyl=32 and sec/trk=64 in the label, which gives me
>1MB `cylinders'.  (Well, I record the drive-reported geometry in the
>ASCII string field in the label, but that's purely for human
>consumption.)  Then I just let there be a partial `cylinder' at the end
>of the disk; it doesn't hurt anything.

By contrast, I *try* to use the geometry reported by the drive *IF* it
will also satisfy the requirements imposed by BIOS (since I move
drives physically from one machine/architecture to another).
Barring that, I try to tweek the geometry to something that is
"harmonicly related" (ha!  :>) to the reported geometry -- though
it seems that drive manufacturers *like* using prime numbers
in their geometries  :-/

It's also worth noting that the "cylinder number" commentary
added by disklabel(8) is often bogus (yet another send-pr(8) coming... :>)

--don