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

[Bruce Cran]

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.

> 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.
> There are many to choose from :-), but only 1 or 2 (if any) to report
> -- the default one and the current one.  Capabilities reporting
> should make it clear if the default one can be changed.  I consider
> CHS features to be unimportant, so they should be reported if the
> capabilites reporting tries to be complete; otherwise they are
> optional.  hdparm for Linux always seemed to report more features
> than atacontrol.

From more testing I've done today it seems that drive manufacturers
have ignored the specifications that say certain fields are obsolete:
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
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?

> 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.

> Now I see more clearly that these are only the "firmware" = default
> parameters.  There are also the current parameters in words 54-58.
> These are not reported here.  One use for reporting them here is
> to make it easy to debug whether the kernel code for using them is
> ever reached :-).  I don't know if a full unfakedparameter struct is
> available here for easy printing.  If it is, then the capabilities
> flag for words 54-58 is in it, and should be used instead of atarev
> for deciding whether to print these words (though setting of
> capability bits for old drives is as unreliable as setting the
> capability words.  The driver seems to trust it).

We should definitely be printing the current geometry, since that's
what the BIOS has 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.

> So I'd be happy if you changed this, so everyone sees any problems in
> this area :-).  Its main inconsistency seems to be that only CAM ad
> does it.

If I was updating it I'd also update the old ad(4) driver to match.

-- 
Bruce Cran