From owner-freebsd-fs@freebsd.org Mon Feb 15 20:33:13 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 92001AA862F for ; Mon, 15 Feb 2016 20:33:13 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp003.me.com (mr11p00im-asmtp003.me.com [17.110.69.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 812CB1CE0 for ; Mon, 15 Feb 2016 20:33:13 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from [172.20.10.3] (unknown [172.56.38.124]) by mr11p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O2L003QIVR69O00@mr11p00im-asmtp003.me.com> for freebsd-fs@freebsd.org; Mon, 15 Feb 2016 20:33:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-02-15_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1602150340 User-Agent: Microsoft-MacOutlook/0.0.0.160109 Date: Mon, 15 Feb 2016 12:33:04 -0800 Subject: Re: Hours of tiny transfers at the end of a ZFS resilver? From: Ravi Pokala Sender: "Pokala, Ravi" To: "freebsd-fs@freebsd.org" Message-id: <8E04E52A-2635-4253-8140-F69495D7D0A6@panasas.com> Thread-topic: Hours of tiny transfers at the end of a ZFS resilver? MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 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: Mon, 15 Feb 2016 20:33:13 -0000 >Date: Mon, 15 Feb 2016 21:18:59 +1100 >From: Andrew Reilly >To: freebsd-fs@freebsd.org >Subject: Hours of tiny transfers at the end of a ZFS resilver? >Message-ID: <120226C8-3003-4334-9F5F-882CCB0D28C5@bigpond.net.au> >Content-Type: text/plain; charset=us-ascii > >Hi Filesystem experts, Hi Andrew, I am in no way, shape, or form a filesystem expert. :-) I *am*, however, an ATA drive expert. I wanted to clarify something you said, because it seems to be a common misunderstanding. >... the new drives actually have 4096B sectors (although they lie about that in smartctl -i queries): They're not lying. >Sector Sizes: 512 bytes logical, 4096 bytes physical Right there - "Sector Size: ... 4096 bytes physical". This is 512B logical / 4KB physical scheme is called AF-512e, and is a documented, standard format. https://en.wikipedia.org/wiki/Advanced_Format#512e The intent is to allow backwards-compatibility with software going back decades, which only knows about 512-byte sectors. Such software would treat an AF-512e drive the same as any other drive. The trade-off is performance, because the drive has to transparently perform read-modify-write operations (for sub-4096B writes), and read the full 4096B physical sector even if only a single 512B logical sector was requested. (Ditto if a properly-sized but un-aligned request were made.) I know GEOM reports both the logical and physical sector sizes (as the provider's "sectorsize" and "stripesize", respectively), and I know that the ATACAM driver is populating them correctly based on the drive's IDENTIFY_DEVICE information. (My very first submission to the project was to fix some bugs in this code; r262886, 2014-03-07.) [*] I *don't* know if ZFS does the right thing automatically; it might not be able to determine what "the right thing" is in all cases. I leave answering that to the actual ZFS experts. :-) -Ravi (rpokala@) [*] 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