>>> I don't know about disktab specifically, since I never use disktab.
>>> But I can say that in my experience, neither of the constraints you
>>> mention applies to the label.
>
>> Then how does the driver know:
>> - where partitions begin and end
>
>The label, which it reads off the disk (usually sector zero) when the
>drive is first accessed.


Yes, but the label also contains geometry information.  Are
you claiming that this is *ignored*?  I.e. could I scribble
"0"s in all the fields and not notice *any* side-effects?

>> - the extents of the physical drive
>
>The drive reports its sector count at probe time.
>
>> - where to "avoid"
>
>Huh?  I don't know what you're referring to here.  Perhaps I'm just
>misinterpreting your smiley....

I was referring to the partition table.

And, also, the "magic" that causes the drive to avoid
"sector 0" regardless (???) of which partition it
appears in.  I.e. placing a BSD partition at "0"
*or* SWAP at "0"!  (or, is this a mistake waiting to happen?)

>> I note that the installer *always* comes up with a geometry that
>> doesn't satisfy the ns/nt/nc criteria mentioned above.
>
>I'd guess you've *always* used ZBR drives, for which there is no single
>true geometry triple, as you mention.


No, years ago (actually, ages ago thursday) I used fixed
geometry drives.  But, recent times are all "variable
density" drives.

>> And, often doesn't seem to correspond to the documented geometry of
>> the drive (from published specifications, etc.).
>
>This I've never seen, except on i386 boxen, where the BIOS gets

Yes.  And installers that try to be too smart...

>underfoot.  There, I've always just let it do whatever it defaults to
>doing and it's always gotten it right so far.  (The fragility of this
>procedure and the underlying lack of understanding of what's really
>going on are among the reasons I tend to avoid i386 boxen.)


I had problems installing 1.5.1 and 1.5.2 on i386 because
it mangled the (IDE) geometry figures.

>> Of course, with zone density recording, there is no true "sectors per
>> track".  But, does *anything* in the system examine these parameters?
>> Or, does it just treat the drive as an array of sequential block
>> numbers?
>
>"Yes."
>
>If you use FFS filesystems, the FFS code uses the geometry information
>in an attempt to do "good" block layout.  Of course, this effort is
>futile in these days of caches larger than tracks, delayed-writeback
>caches, ZBR, DMA that can't keep up with the platters, etc.  But it's
>easier to let it have its little delusions than to try to rip all that
>code out.  So yes, something does look at those numbers.  But if
>they're wrong, it may impair performance (and probably not even that by
>much, these days), but won't impair correctness.
>
>At the filesystem<->driver interface, the drive is just a big linear
>array of blocks.
>
>Below that, it depends on the interface.  SCSI disks are addressed by
>sector number.  IDE disks may or may not be; I think this is LBA
>addressing versus CHS addressing.  (Fuzzy memory says there is a third

But, if CHS addressing is used, then the geometry is significant.
Getting it wrong can lead to "undefined" behaviour (i.e. depends on
how the drive decideds to handle it as well as how the OS
(mis)applies the translations.  I.e. if the OS thinks in terms
of a linear array of sectors and the driver translates this
to CHS based on an incorrect geometry, then a request for sector
27 gets translated to two different *physical* sectors
depending on the "ns" parameter.  IIRC, this is how FreeBSD
managed to "walk past the end" of my disk...

So, back to my original question:  does *anything* look
at the CHS figures in the drives geometry (as carried in
the disklabel -- which brings us back to the disktab issue)

>option, but I know nothing more about it.)  Others, well, it depends.
>I think most floppy hardware is fundamentally cyl/hd/sec addressed.
>MSCP I'm not sure of (it's been too long) but I think they're big-array
>addressed.  HP-IB, etc, who knows?  Maybe people who know other
>architectures can speak to the idiosyncracies of their architectures.


--don