From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:59:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 04C16F8 for ; Fri, 19 Sep 2014 23:59:33 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA487CC9 for ; Fri, 19 Sep 2014 23:59:31 +0000 (UTC) Received: from jt-mbp.sldomain.com (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8JNxIVV060969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 17:59:20 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Subject: Re: getting to 4K disk blocks in ZFS Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: "Justin T. Gibbs" X-Priority: 3 In-Reply-To: Date: Fri, 19 Sep 2014 17:59:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <82FFB2B2-F1D7-422A-BA92-9AFE95678390@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> <541CBD5B.8050603@denninger.net> To: Steven Hartland X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org, Karl Denninger X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 23:59:33 -0000 On Sep 19, 2014, at 5:43 PM, Steven Hartland = wrote: >=20 > ----- Original Message ----- From: "Karl Denninger" = >=20 >> >> I'm surprised that we have to constantly add quirks. Are these >> >> drives really >> >> failing to report their ata params correctly? Is there a reason = we >> >> don't >> >> currently utilize the ata params data (which is already fetched = for >> >> trim/unmap >> >> detection) to also set lbppbe (logical block per physical block >> >> exponent) and >> >> lalba (lowest aligned lba)? We may find that many of the existing >> >> quirks are >> >> unnecessary if we fix the probe code. >> > >> > On the contary I've not found a single drive which reports 4k = sectors >> > on its >> > own, every single one that I've seen report 4k is because we've = added a >> > quirk for it :( >> > >> > >> Where is Smartctl getting it from? >> smartctl -i /dev/da2 >> smartctl 6.3 2014-07-26 r3976 [FreeBSD 10.1-BETA1 amd64] (local = build) >> Copyright (C) 2002-14, Bruce Allen, Christian Franke, = www.smartmontools.org >> =3D=3D=3D START OF INFORMATION SECTION =3D=3D=3D >> Device Model: HGST HDN724040ALE640 >> Serial Number: PK2334PCG6NA0B >> LU WWN Device Id: 5 000cca 24cc30684 >> Firmware Version: MJAOA5E0 >> User Capacity: 4,000,787,030,016 bytes [4.00 TB] >> Sector Sizes: 512 bytes logical, 4096 bytes physical >> Rotation Rate: 7200 rpm >> Form Factor: 3.5 inches >> Device is: Not in smartctl database [for details use: -P = showall] >> ATA Version is: ATA8-ACS T13/1699-D revision 4 >> SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) >> Local Time is: Fri Sep 19 18:33:16 2014 CDT >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> It's not coming from a database, as Smartctl doesn't know about these >> (yet); they're too new. >=20 > Exception to prove the rule? >=20 > What to "camcontrol identify da2" report? Was there some recent change made to have that command report sector = size information? Last I checked, it didn=92t. =97 Justin=