Date: Thu, 9 Dec 2010 22:14:58 +0000 From: Bruce Cran <bruce@cran.org.uk> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon <avg@freebsd.org>, 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: <20101209221458.42448075@core.draftnet> In-Reply-To: <20101209191657.B1400@besplex.bde.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. =46rom 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" =3D 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=3D255/C=3D63 which matches all metadata. When I boot -current it > generates H=3D16/C=3D63. 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. --=20 Bruce Cran
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101209221458.42448075>