Date: Fri, 10 Dec 2010 22:47:08 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Erik Trulsson <ertr1013@student.uu.se> Cc: Bruce Cran <bruce@cran.org.uk>, src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon <avg@freebsd.org>, Bruce Evans <brde@optusnet.com.au>, Bruce Cran <brucec@freebsd.org>, svn-src-head@freebsd.org, Matthew Jacob <mj@feral.com> Subject: Re: svn commit: r216269 - head/sys/geom/part Message-ID: <20101210213131.Y1980@besplex.bde.org> In-Reply-To: <20101210010023.GA68703@owl.midgard.homeip.net> References: <201012072046.oB7KkB4L079555@svn.freebsd.org> <4CFEAD09.30904@freebsd.org> <4CFEAFA6.4020103@feral.com> <4CFEB1AD.70906@freebsd.org> <20101208153857.H1428@besplex.bde.org> <20101208225235.501ced0e@core.draftnet> <20101209191657.B1400@besplex.bde.org> <20101209221458.42448075@core.draftnet> <20101210010023.GA68703@owl.midgard.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101210213131.Y1980>