>der mouse volunteered:

>> For example, does the total number of sectors (su) override the
>> effective unit size (ns * nc * nt)?  Or, *must* they agree?
>
>> In more practical terms, if the drive reports N sectors (and you
>> *assume* this to be Gospel), *must* you define a geometry that
>> coincides with this; does not *exceed* this; or, is the geometry
>> largely immaterial?
>
>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 extents of the physical drive
- where to "avoid"

:>

I.e. why not use rand() to create disklabels?  (facetious, of course)

I note that the installer *always* comes up with a geometry that
doesn't satisfy the ns/nt/nc criteria mentioned above.  And, often
doesn't seem to correspond to the documented geometry of the
drive (from published specifications, etc.).

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?

>> I ask since I had problems some years ago under FreeBSD where the
>> system was using a bogus geometry instead of the actual geometry.  As
>> a result, the system thought the drive was bigger than it really was.
>> Since my swap happened to be at the end of the drive, the problem
>> would only turn up when swap was heavily used.  And, of course, this
>> was not a "graceful recovery"!
>
>I've never had such trouble, but I've always been careful that
>partitions that end at the "end" of the disk always end at the actual
>end, not at the end of what the label thinks is the last cylinder.

That was my point.  The example I mentioned was a consequence of
FBSD listening to the "manufacturer's geometry" reported by the
drive instead of the *actual* (translated) geometry that the BIOS 
had previously INITIALIZEd (ATAPI) the drive with.  I.e. drive
was operating in one geometry, FBSD was using another.  Obviously, 
FBSD was making assumptions based on the geometry

>Indeed, the tool I use to repartition warns if I set a partition to end
>after what the total-sector-count field says is the end of the disk.