From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:07:49 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 174C84DD; Fri, 19 Sep 2014 23:07:49 +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 D859487F; Fri, 19 Sep 2014 23:07:48 +0000 (UTC) Received: from [192.168.6.121] (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 s8JN7YwK060738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Sep 2014 17:07:36 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: getting to 4K disk blocks in ZFS From: "Justin T. Gibbs" In-Reply-To: <541230F1.3060402@digiware.nl> Date: Fri, 19 Sep 2014 17:07:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> References: <540FF3C4.6010305@ish.com.au> <54114029.3060507@FreeBSD.org> <2128347.Ah5i0RTCvp@overcee.wemm.org> <541230F1.3060402@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Cc: Steven Hartland , freebsd-stable@freebsd.org, Andriy Gapon , Peter Wemm , Aristedes Maniatis 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:07:49 -0000 On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen = wrote: > On 11-9-2014 19:49, Peter Wemm wrote: >>> Another downside is 1/4th of uberblocks, 32 vs 128. >>> Also, automatic sector size detection works great for me and I've = never had >>> a need to manually tweak ashift. >>=20 >> Unfortunately, I have. Same drive connected two different ways: >>=20 >> da12 at mps1 bus 0 scbus1 target 11 lun 0 >> da12: Fixed Direct Access SCSI-6 device=20= >> da12: 600.000MB/s transfers >> da12: Command Queueing enabled >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) >>=20 >> ada1 at ahcich1 bus 0 scbus3 target 0 lun 0 >> ada1: ATA-8 SATA 3.x device >> ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada1: Command Queueing enabled >> ada1: 3815447MB (7814037168 512 byte sectors: 16H 63S/T 16383C) >> ada1: quirks=3D0x1<4K> >>=20 >> The 4k flag is missing when it's on the sas controller. The Ident = strings are=20 >> changed. >>=20 >> This came up elsewhere recently. >=20 > I reported the same fact for the new set of WD REDs I installed. > Seems that ada and da have different quirks tables... > So disks on SATA connectors on the motherboard are diagnosed as being = 4Kb. > The disks on my twa don't get the quirk and are considered 512b >=20 > =97WjW I=92m 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=92t 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. =97 Justin=