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

Bruce Evans brde at optusnet.com.au
Fri Dec 10 11:47:32 UTC 2010


On Fri, 10 Dec 2010, Erik Trulsson wrote:

> On Thu, Dec 09, 2010 at 10:14:58PM +0000, 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.
>
> Modern drives do not really report 'the current CHS geometry'. They
> report a fake geometry that normally do not have anything do with the
> actual geometry.

No.  The report the current CHS translation mode (if they support CHS
and also support programming the CHS translation).  This is the 'current
CHS geometry'.  It is reported in words 54-58 (if programming the CHS
translation is supported, and the drive is not so old as to not support
words 54-58 to indicate that non-null programming has been done).
It has nothing to do with any physical geometry, unless the drive is
so old as to have a representable physical geometry, and the current
CHS geometry equals the physical geometry (either by defaulting to it
or by beinbg changed to it).  But it is very real.  You have to use
it if you talk to the drive in CHS mode.

The current CHS geometry should not be confused with the default CHS
geometry.  This is in words 1, 3 and 6.  All drives that support CHS
mode have this.  On very very old drives, this is the physical geometry
and there is no way to change it.  On very old drives, this is a fake
geometry and there is no way to change it.  On old drives, this is a
fake geometry and anyone can change it to another fake geometry.  When
the geometry is fake, it is really the current CHS translation mode,
but that takes too long to write so everyone still calls it the geometry
except when technical precision is required.

> (As an example just about all modern ATA/SATA drives
> report having 16 heads, while in reality none of them have more than 10
> heads and most of them have fewer heads than that.)

That is their default CHS translation mode.  Old drives reported having
even more heads, so that all disk addresses could be represtented in CHS,
but that started to break about 12 years ago when average drive sizes 
started exceeding 8GB, and broke about 10 years ago when average drive
sizes started exceeding 32GB (8GB is where BIOSes start breaking and
32GB is where CHS translation breaks), so about 10 years ago ATA started
specifying that the default CHS translation mode be H=16/S=63 for drives
larger than a certain size since no CHS translation can cover the whole
drive and H=16/S=63 is safer for the BIOSes that broke at 8GB.  Except
I think it changes the breakage point from 8GB to 512MB for some.

However, if the drive supports programming the CHS translation, then
anyone can change the translation.  This is even useful.  H=16/S=63
can only reach the first 512MB of a disk for very old BIOSes that
don't change it and also have a limit of C=1024.  Old BIOSes that
change it but which still have a limit of C=1024 and which don't
add an extra level of fakery (translation) can reach 8GB by changing
it to H=255/S=63 (CHS supports H=256, but that is unsafe with most
BIOSes since allthough the maximum number of fake heads with H=256 is
255, some BIOS interface store the number of heads in a byte, and 256
doesn't fit).  Not so old BIOSes still have a limit of C=1024, but
this is not a limit on CHS except on pre-IDE drives (I think this
limit started at 256, then was increased to 1024, and finally to
65536 before the interface ran out of bits at 128GB and LBAA48 became
required).

> Finding out the real geometry of a disk is generally not possible and
> typically cannot even be expressed with a simple C/H/S scheme, since the
> 'S' component is usually not a constant. (Modern drives put more
> sectors per track on the outer tracks than on the inner tracks.)

No one cares about that.  The BIOS gemetry needed for putting in MBR
entries for old OS's and boot loaders is the fake geometry that is
expected or supported by the old software.  This is sometimes the
default CHS translation mode.  On OS's that need this, it is more often
the current CHS translation mode.  Since FreeBSD doesn't need this,
it is rarely either of the CHS translation modes.  Since FreeBSD doesn't
support this, but still needs a fake geometry, the best it can do is
report both CHS translations for external use and distinguish them from
its internal fake geometry.

> The only reason for actually using the geometry reported by the disk
> for anything is if you need to have the partitioning of the disk
> compatible with some other OS which does use the reported CHS values.
> (E.g. if you have a dual-boot machine where FreeBSD shares the disk
> with some other OS that insists on having partitions start exactly on a
> track boundary, then FreeBSD would need to handle that somehow.)
> But even then you are not really interested in using the 'correct'
> geometry, but rather in using whatever geometry that other OS is using.

Correct.  FreeBSD used to support this, but GEOM dropped the support.
In 386BSD, the geometry that seemed to be used in the partition table
was even used by the driver (wd) to determine which geometry the CHS
translation mode should be programmed to, or the default fixed CHS
translation mode if the translation was invariant.  The driver itself
confused the geometry needed to talk to the drive with the one needed
for the MBR.

Bruce


More information about the svn-src-all mailing list