From owner-freebsd-stable@FreeBSD.ORG Fri Sep 19 23:23:37 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 C127E7D5; Fri, 19 Sep 2014 23:23:37 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 81BAD9FE; Fri, 19 Sep 2014 23:23:37 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 8A40120E7088F; Fri, 19 Sep 2014 23:23:36 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE,TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id C5B9E20E7088A; Fri, 19 Sep 2014 23:23:34 +0000 (UTC) Message-ID: <607F83CE25104CE09C74935BA9E26485@multiplay.co.uk> From: "Steven Hartland" To: "Justin T. Gibbs" , "Willem Jan Withagen" 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> Subject: Re: getting to 4K disk blocks in ZFS Date: Sat, 20 Sep 2014 00:23:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org, Peter Wemm , Andriy Gapon , 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:23:37 -0000 ----- Original Message ----- > From: "Justin T. Gibbs" > To: "Willem Jan Withagen" > Cc: "Steven Hartland" ; ; "Andriy Gapon" ; "Peter Wemm" > ; "Aristedes Maniatis" > Sent: Saturday, September 20, 2014 12:07 AM > Subject: Re: getting to 4K disk blocks in ZFS > > > 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. > >> > >> Unfortunately, I have. Same drive connected two different ways: > >> > >> da12 at mps1 bus 0 scbus1 target 11 lun 0 > >> da12: Fixed Direct Access SCSI-6 device > >> da12: 600.000MB/s transfers > >> da12: Command Queueing enabled > >> da12: 3815447MB (7814037168 512 byte sectors: 255H 63S/T 486401C) > >> > >> 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=0x1<4K> > >> > >> The 4k flag is missing when it's on the sas controller. The Ident strings are > >> changed. > >> > >> This came up elsewhere recently. > > > > 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 > > > > —WjW > > 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 :( Regards Steve