From owner-freebsd-stable@FreeBSD.ORG Sat Sep 20 06:21:46 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 E685C3A8; Sat, 20 Sep 2014 06:21:46 +0000 (UTC) Received: from aslan.scsiguy.com (www.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 B642F171; Sat, 20 Sep 2014 06:21:46 +0000 (UTC) Received: from [192.168.0.61] (jt-mbp.home.scsiguy.org [192.168.0.61]) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id s8K6LZhF062711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 20 Sep 2014 00:21:37 -0600 (MDT) (envelope-from gibbs@scsiguy.com) 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: <7D0869A9-C114-4C4F-877A-3FB26AD7737D@scsiguy.com> Date: Sat, 20 Sep 2014 00:21:36 -0600 Message-Id: <9F3CB84B-E0F1-4343-8E37-4E4A9F252C52@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> To: Willem Jan Withagen X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Sat, 20 Sep 2014 06:21:47 -0000 On Sep 19, 2014, at 5:07 PM, Justin T. Gibbs wrote: > On Sep 11, 2014, at 5:32 PM, Willem Jan Withagen = wrote: >=20 >> 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 >=20 > 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. >=20 > =97 > Justin Here=92s a start at using the ata_params sector size data. I think it = needs to go a bit further and detect situations where the SCSI = controller=92s emulation gets the logical sector size wrong and fail to = attach - but I=92m out of steam for tonight. Note that this patch is against Spectra Logic=92s FreeBSD/stable/10=92ish = tree, so may not apply cleanly for you as is. I can rebase it against = head tomorrow if there is interest and someone else doesn=92t beat me to = it.