Date: Wed, 8 Dec 2010 16:46:17 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andriy Gapon <avg@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Matthew Jacob <mj@feral.com>, Bruce Cran <brucec@freebsd.org> Subject: Re: svn commit: r216269 - head/sys/geom/part Message-ID: <20101208153857.H1428@besplex.bde.org> In-Reply-To: <4CFEB1AD.70906@freebsd.org> References: <201012072046.oB7KkB4L079555@svn.freebsd.org> <4CFEAD09.30904@freebsd.org> <4CFEAFA6.4020103@feral.com> <4CFEB1AD.70906@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101208153857.H1428>