From owner-svn-src-head@FreeBSD.ORG Thu Dec 9 22:15:13 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01186106564A; Thu, 9 Dec 2010 22:15:13 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id 38C008FC17; Thu, 9 Dec 2010 22:15:12 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 59D4DE717A; Thu, 9 Dec 2010 22:15:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=mail; bh=C/Wy9dyIWUV5 FnQKsf/u8gbMHjs=; b=Rj8i0pp1CxzksN8JxUzr915aHcPQEzqnqgs8zpF87ff6 LhrCKEFzXaNAYlwv4T1cHS35rLPLnDBeQr37UwrnnLe7iSAHLK2tePKxOlU5p8kY rG2WMZhE3JRQ3OlJceb7V9pp/IyrsaUfSgcZqmc0WCyV01KQw4pOsmUs9m3giaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=date:from:to :cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=mail; b=izlKV3 Gcxh/6NKfuZlfyrjbEqSxvqJ5oQN/GzUrmfPBXNg/IsQ6tp1uo6bPM05cZ48a2Tm KHLVAExWiWBphTU0u3VPKtyoNCaWptU8pro4S8BQ5PtnUkdvcdAn5UYY6sXgt/Lh kG9rlva+PvQyeuYxrL8duE17Cz6oD/3pdRd6g= Received: from core.draftnet (client-86-27-21-134.glfd.adsl.virginmedia.com [86.27.21.134]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 0D87EE7178; Thu, 9 Dec 2010 22:15:09 +0000 (GMT) Date: Thu, 9 Dec 2010 22:14:58 +0000 From: Bruce Cran To: Bruce Evans 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> X-Mailer: Claws Mail 3.7.7 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, Andriy Gapon , Bruce Cran , svn-src-head@freebsd.org, Matthew Jacob Subject: Re: svn commit: r216269 - head/sys/geom/part X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 22:15:13 -0000 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. > 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