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

[Bruce Evans]

On Thu, 9 Dec 2010, Bruce Cran wrote:

> On Thu, 9 Dec 2010 19:58:56 +1100 (EST)
> Bruce Evans <brde at optusnet.com.au> wrote:
>
>> I had understood the ATA_FLAG_54_58 backwards.  It tells us if the
>> drive is not so old that it doesn't support IDENTIFY records for
>> words 54-58.  I think we rarely get here.  Drives old enough to use
>> CHS may be so old that they don't support words 54-58.  Only drives
>> manufactured during a few years or months in the 1990's will support
>> words 54-58 but not LBA. Maybe I'm misremembering the length of this
>> time.
>
> All modern drives (including ATA-8) seem to support reporting the
> current CHS geometry, so FreeBSD will use this for the geometry;
> however since when the BIOS chooses to use LBA mode the "current
> geometry" words aren't updated I think we use the wrong geometry on
> modern drives.

The BIOS has little control over the mode.  It can't enforce LBA if the
drive supports CHS.  It can't force any particular CHS mode since the
driver may set any CHS mode.  ata used to reset the drive in the probe
and in reinit.  I think this is a hard reset which restores the default
CHS.  I can't see where ata resets now.  It is nicely obfuscated using
function pointers.  I think it does less resetting.  It also has a
soft reset for at least sata, but sata won't be using CHS.  Removing of
resets would explain why it now has to use the current CHS (since it
doesn't change the CHS back to the default).

>> I don't like this.  If the drive supports CHS, then its geometries for
>> this should be reported, if CHS reporting is implemented at all.
>> ...
>
>> From more testing I've done today it seems that drive manufacturers
> have ignored the specifications that say certain fields are obsolete:

Obsolete doesn't mean that it is require to be broken.

> on an ATA-7 drive setting the BIOS mode to CHS and the number of
> heads to 8 results in word 55 being updated; all the modern (ATA-7 and
> ATA-8) drives I've tested report words 54-58 as being valid. So should

If they support using CHS, and also support changing CHS, then they
have to have these words to report what the change was.

> we be using an older version of the spec and printing obsolete fields
> too? As it is, we don't have a fallback position if a manufacturer does
> decide to stop supporting CHS. Should we perhaps be using the LBA mode
> settings (65535/255/63) if the disk is over 8GB?

The driver always ignores CHS (except to report it) and uses LBA if
possible.  If a manufacturer stops supporting CHS, then the driver
shouldn't notice, but the manufacturer's non-support should include
setting the obsolete fields to 0 (or possibly other specified magic
numbers).  It is then up to utilities whether to report these fields
as simply there value or to decrypt their magic values into a CHS-
unsupported flag (I don't know of any actual flag for this).  Then
there is the "firmware geometry" reported to GEOM.  You could try
changing this to 0/0/0 and see what breaks.  CAM for SCSI drives still
invents a geometry to avoid seeing evil here, since SCSI drives have
only had no geometry for about 30 years now.

>> I don't like removing them depending on the version.  atacontrol is
>> about the only place that you can see CHS without it possibly having
>> gone through several layers of fakery.
>
> Since it appears that disks are still using the CHS fields despite
> having been obsolete since ATA-7 I guess it makes sense to continue
> printing them.

Not really.  Disks aren't users, but may support their use.  Drivers
aren't using them, but should be reporting when they are useable and
also their values if use is supported and configured.

>> Risky to change this so late.  Actually, I have too much experience
>> with the system generating wrong geometries, and it goes the other
>> way.  I normally run older FreeBSDs which generate the BIOS geometry
>> of H=255/C=63 which matches all metadata.  When I boot -current it
>> generates H=16/C=63. I get annoyed by disk^Wbsdlabel complaining
>> about this and more, and can't risk using it to change labels.
>
> I had presumed that since bsdlabel(8) says the geometry values are
> historical that they weren't actually used anywhere. However I now see
> that it appears that fsck_ffs does interpret the geometry at least for
> UFS1.

Urk.  For ffs1, it seems to be rounding important parameters to track
and cylinder boundaries.  It divides by d_secpercyl.  So you would
soon find that a geometry of 0/0/0 doesn't work :-).

Bruce