From owner-svn-src-all@FreeBSD.ORG Thu Dec 9 23:12:49 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A76A106564A; Thu, 9 Dec 2010 23:12:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id F40BD8FC12; Thu, 9 Dec 2010 23:12:48 +0000 (UTC) Received: from c122-106-172-0.carlnfd1.nsw.optusnet.com.au (c122-106-172-0.carlnfd1.nsw.optusnet.com.au [122.106.172.0]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB9NCY0T008212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 10:12:35 +1100 Date: Fri, 10 Dec 2010 10:12:34 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Cran In-Reply-To: <20101209221458.42448075@core.draftnet> Message-ID: <20101210092805.M8539@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> <20101209221458.42448075@core.draftnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon , Bruce Evans , Bruce Cran , svn-src-head@freebsd.org, Matthew Jacob Subject: Re: svn commit: r216269 - head/sys/geom/part X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 23:12:49 -0000 On Thu, 9 Dec 2010, Bruce Cran wrote: > On Thu, 9 Dec 2010 19:58:56 +1100 (EST) > Bruce Evans 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. The BIOS has little control over the mode. It can't enforce LBA if the drive supports CHS. It can't force any particular CHS mode since the driver may set any CHS mode. ata used to reset the drive in the probe and in reinit. I think this is a hard reset which restores the default CHS. I can't see where ata resets now. It is nicely obfuscated using function pointers. I think it does less resetting. It also has a soft reset for at least sata, but sata won't be using CHS. Removing of resets would explain why it now has to use the current CHS (since it doesn't change the CHS back to the default). >> 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. >> ... > >> From more testing I've done today it seems that drive manufacturers > have ignored the specifications that say certain fields are obsolete: Obsolete doesn't mean that it is require to be broken. > 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 If they support using CHS, and also support changing CHS, then they have to have these words to report what the change was. > 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? The driver always ignores CHS (except to report it) and uses LBA if possible. If a manufacturer stops supporting CHS, then the driver shouldn't notice, but the manufacturer's non-support should include setting the obsolete fields to 0 (or possibly other specified magic numbers). It is then up to utilities whether to report these fields as simply there value or to decrypt their magic values into a CHS- unsupported flag (I don't know of any actual flag for this). Then there is the "firmware geometry" reported to GEOM. You could try changing this to 0/0/0 and see what breaks. CAM for SCSI drives still invents a geometry to avoid seeing evil here, since SCSI drives have only had no geometry for about 30 years now. >> 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. Not really. Disks aren't users, but may support their use. Drivers aren't using them, but should be reporting when they are useable and also their values if use is supported and 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. Urk. For ffs1, it seems to be rounding important parameters to track and cylinder boundaries. It divides by d_secpercyl. So you would soon find that a geometry of 0/0/0 doesn't work :-). Bruce