svn commit: r216269 - head/sys/geom/part

[Bruce Evans]

On Wed, 8 Dec 2010, Andriy Gapon wrote:

> on 08/12/2010 00:05 Matthew Jacob said the following:
>>
>>
>> On 12/7/2010 1:54 PM, Andriy Gapon wrote:
>>> on 07/12/2010 22:46 Bruce Cran said the following:
>>>>    Don't warn if a partition appears not to be aligned on a track boundary.
>>>>    Modern disks use LBA and create a fake CHS geometry that doesn't have any
>>>>    relation to the on-disk layout of data.
>>> You repeated that statement, so I am picking on you :-)
>>> Can someone show me how/where exactly modern drives fakes CHS geometry?
>>
>> cf cam_calc_geometry
>
> But that's not drive firmware code :-)

Indeed.

> It's us faking those parameters for ourselves for some unknown reason.
> Stupid us :-) But not the drives / manufacturers.

Faking the geometry, and determining the correct fake, goes back at
least 20 years to Adaptec SCSI BIOSes for host adaptors.  AFAIK, SCSI
drives never had any CHS geometry, fake or otherwise.  But some O/S's
wanted CHS.  This was faked in BIOS ROMs for at least the better host
adaptors, since booting is too hard if it is only in a driver loaded
from a file system.

Originally the fake was fairly statically configured using rules like
the ones in cam_calc_geometry(), but different adaptor manufacturers
used different rules (or maybe there was a jumper or BIOS option to
control the behaviour, but this was too confusing for users) so there
were large problems changing the adaptor.  So BIOSes started attempting
to determine the CHS geometry that is actually used by O/S's, according
to partition table entries, and supplied that as a fake instead of
their default fake.  This caused different large problems changing the
adaptor, when bugs or differences in the algorithm caused different fakes
to be determined.

FreeBSD used to try to determine determine the CHS geometry that is
actually used by O/S's, using similar algorithms to the BIOSes.  This
has been lost to GEOM.  GEOM now "uses" whatever geometry is supplied by
lower layers.  I know of the following cases:
- for SCSI drives, I think it uses the fake generated by
   cam_calc_geometry().  This is not too bad.  It would have been invariant
   over the last for 20-30 years if SCSI BIOSes had agreed on it originally.
   Perhaps the SCSI standard now specifies this.  Unfortunately,
   cam_calc_geometry() has no comment about this.
- I think the next case would break pc98, so pc98 uses a hook to supply
   a more compatible default.
- for ATA drives, it uses the "firmware" geometry supplied by the drive
   firmware.  The ATA standard specifies this to be H=16/S=63 for all
   drives larger than a certain size (IIRC, about 8GB, which is the size
   at which the better default fake of H=255/S=63 generated by
   cam_calc_geometry() for drives larger than 1GB, stops working for
   systems that can't handle more than 1024 fake cylinders.  The magic
   1GB is the size at which the even better default fake of H=64/S=32
   stops working with more than 1024 fake cylinders.  cam_calc_geometry()
   has no comment about this either).  Since all modern ATA drives are
   larger than 8GB, H=16/S=63 is almost hard-coded for ATA.

This results in GEOM "using" a geometry that is wrong in many cases
for non-pc98 ATA drives, since many were configured with H=255/S=63.
The other cases are more compatible.  After this commit, GEOM hopefully
doesn't actually use the CHS geometry for anything.  It should just
report it to userland, and should get it right for that.  The correct
geometry has little to do with the "firmware" geometry.  It is whatever
the BIOS or disks are using, if anything is still using CHS.  Modern
BIOSes should "use" CHS in the same way that GEOM should, that is,
never, but they should report it for old software to use, and should
get it right for that.  I don't know how far they have got towards
that.  Some support H=16/S=63 but default to weird geometries.  Some
allow this to be configured.  I always configure to "LBA" (H=255/S=63)
for compatibility.

>>> Let me specifically ask that question about modern (S)ATA drives directly
>>> connected to a system (controller).
>>> My impression is at least since ATA-7 there is no mentioning of anything
>>> CHS-related in the specification.  The fact that we keep reading and
>>> interpreting some historically defined bytes that are now marked as
>>> unused/reserved doesn't mean that those bytes actually mean anything.

Aren't they optional?  Last time I looked at the ATA standard (5-10
years ago), IIRC it said that support for CHS translation mode is
optional, but when it is supported all the fields for using it (the
default translation mode (always H=16/C=63 for modern drives) and the
current translation mode) must be supported.  I guess support for it
is now so cheap that most manufacturers support it for compatibility.

Bruce