From owner-freebsd-fs@freebsd.org Tue Feb 16 09:09:16 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22D3EAA825B for ; Tue, 16 Feb 2016 09:09:16 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7F071A42 for ; Tue, 16 Feb 2016 09:09:15 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x230.google.com with SMTP id c200so149445172wme.0 for ; Tue, 16 Feb 2016 01:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=fQA6Sdh5LFMW10vym2/vyESbN0H1Cw7Ry3m4QU2zZJs=; b=B2MsIv5/nQNIfYuSDl/p+4TCOlB2YpuiNZ04TxJRh8FCc39VUFbVe6Yhi1Kc3134VY AeN+EoczmbrzORgZq4eNyCxc+/u1HovAnW5J78EtBUd86y7vRtNiMVvctbR5Po00qm0y y7WGih31m+JxCuGWUD/KCltfc8ExdkVnNa16aM+npsJme9SdDae4iERpj1tYt9vyc7yi xo1qcAJKCSA/hLXHoUox/lVIrBMRhFZqXRkrtnfK4bWzs9NYgeMw8Ru7avFHimvVj9FW MTCyt2xPneIPBOqCceJczBkIiSN9NKHZSEEK4+y60M3Hluy31AMUfz4HZ/0cLZchOU9B ENzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=fQA6Sdh5LFMW10vym2/vyESbN0H1Cw7Ry3m4QU2zZJs=; b=DDDP40ZzbzXZJCkSE/lD8zeW1CNDFJ3VPSuAmoYDdkSD+GYTT1ulS4zGxnhSVCNHMr S1OI3WHsfk7UlQitl9bJP9Uwy/QTAs5dwZfr2wCB3/tutM1mJSLz7TULRWhzkX11Dsl9 fDzzcJf6XGc5KONisbyzmbGHXDJOo21Tj8nfSsqlqJJhlzkX7U07w9m6/QENKwVxmuge ScKX7QULGAWpeJVmYZ6c8dhahx8rpyJoCJJcqpdiz5QQVSsdsO3j2D3YHjzwyomxU5Hj rFlfcJzNjnmI0csXLQS/58RVThgBVi5Z0M+JUmv+sdP6OPbTdDF9a1GpDU88tNwSMclz YC6g== X-Gm-Message-State: AG10YORcdIOTMtuhuJsdbCALX1KRK1tg2dRwLQQizcaYAM0maNdoERN5pT9gb5zAt0Uoi8V6 X-Received: by 10.28.127.5 with SMTP id a5mr18602310wmd.32.1455613753722; Tue, 16 Feb 2016 01:09:13 -0800 (PST) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id gt7sm29286953wjc.1.2016.02.16.01.09.12 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Feb 2016 01:09:12 -0800 (PST) Subject: Re: Hours of tiny transfers at the end of a ZFS resilver? To: freebsd-fs@freebsd.org References: <871E2D0C-C131-407E-A982-6AFE896901F6@panasas.com> From: Steven Hartland Message-ID: <56C2E73D.2010405@multiplay.co.uk> Date: Tue, 16 Feb 2016 09:09:17 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <871E2D0C-C131-407E-A982-6AFE896901F6@panasas.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 09:09:16 -0000 On 16/02/2016 03:31, Ravi Pokala wrote: >> Date: Mon, 15 Feb 2016 21:08:43 +0000 >> From: Steven Hartland >> To: freebsd-fs@freebsd.org >> Subject: Re: Hours of tiny transfers at the end of a ZFS resilver? >> Message-ID: <56C23E5B.7060207@multiplay.co.uk> >> Content-Type: text/plain; charset=windows-1252; format=flowed > Hi Steve, > >>> [*] This is probably a good segue into discussing why we even have the ADA_Q_4K quirk, and whether we should get rid of it...? --rp >> The 4k quirks exists because a large amount of devices don't report 4k correctly instead just reporting 512 for both logical and physical even when they are actually 4k or larger physical sector size. > If true, that's a gross violation of ATA, and I would consider that a disqualifying firmware bug. After over a decade at a storage vendor, I've seen some *really* stupid firmware issues, but lying about the sector size would be a new low. :-( > > Are we sure that they are really, truly claiming to be 512n rather than AF-512e, rather than us mis-parsing the sector sizes due to the aforementioned kernel bugs? If someone running -CURRENT has a drive which has the ADA_Q_4K quirk, could you paste the output of `geom disk list $DRIVE'? > My head box doesn't have the feature that would do what you're after but here's what camcontrol says for one such device: camcontrol identify ada0 pass1: ATA8-ACS SATA 3.x device pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model Corsair Force GS firmware revision 5.05A serial number 1304790400009741003E WWN 0000000000000000 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 250069680 sectors LBA48 supported 250069680 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating This is 4k underlying, SSD's are by far and away the worst culprits for this. Regards Steve