From owner-freebsd-fs@FreeBSD.ORG Wed Oct 12 18:15:13 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F9361065677 for ; Wed, 12 Oct 2011 18:15:13 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by mx1.freebsd.org (Postfix) with ESMTP id AEDAA8FC12 for ; Wed, 12 Oct 2011 18:15:12 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id jsQz1h0061vXlb858uFDmy; Wed, 12 Oct 2011 18:15:13 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta17.westchester.pa.mail.comcast.net with comcast id juEA1h00U1t3BNj3duEAcw; Wed, 12 Oct 2011 18:14:11 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id D30F2102C1C; Wed, 12 Oct 2011 11:14:08 -0700 (PDT) Date: Wed, 12 Oct 2011 11:14:08 -0700 From: Jeremy Chadwick To: mav@freebsd.org Message-ID: <20111012181408.GA27604@icarus.home.lan> References: <4E95AE08.7030105@lerctr.org> <20111012155938.GA24649@icarus.home.lan> <4E95C546.70904@digsys.bg> <20111012172912.GA27013@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: AF (4096 byte sector) drives: Can you mix/match in a ZFS pool? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 18:15:13 -0000 On Wed, Oct 12, 2011 at 10:43:23AM -0700, Artem Belevich wrote: > On Wed, Oct 12, 2011 at 10:29 AM, Jeremy Chadwick > wrote: > > How does ZFS determine this? ?I was under the impression that this > > behaviour was determined by (or "assisted by") ashift. > > > > Surely ZFS cannot ask the underlying storage provider (e.g. GEOM on > > FreeBSD) what logical vs. physical sector size to use (e.g. for SATA > > what's returned in the ATA IDENTIFY payload), because on SSDs such as > > Intel SSDs *both* of those sizes are reported as 512 bytes (camcontrol > > identify confirms). > > In r222520 mav@ added ADA_Q_4K quirks for bunch of Hitachi, Seagate > and WD drives so that geom_disk will be aware of 4K sectors at least > for some disks. > I'm not sure whether ZFS picks it up, though. http://svnweb.freebsd.org/base?view=revision&revision=222520 http://svnweb.freebsd.org/base/head/sys/cam/ata/ata_da.c?r1=222520&r2=222519&pathrev=222520 So it looks like this commit is intended to work around drives which report an incorrect **physical** sector size of 512 bytes. Per disk(9), the stripesize and stripeoffset variables would be used to ensure that partitions/slices/etc. are all aligned to said value. I imagine this would predominantly play a role during partition/slice creation. (This might explain some of the performance weirdness I've seen on some of our RELENG_8 boxes which were built/installed with SSDs off code much older than 4 months ago. Might need to get a newer snapshot and reinstall those...) As such, I believe this quirk list needs SSDs added to it, particularly Intel SSDs, which report 512 physical. Alexander, I can provide you either a patch/diff or a list of Intel SSD model numbers (I have X25-M, 320-series, and 510-series drives available to me easily, and maybe X25-V around here somewhere). All of these drives report 512 physical. I'm familiar with Intel's serial naming scheme (it's documented in some of their PDFs) as well as "oddities" with it (such as when they append "HP" to the string for OEM drives for HP, etc.). Let me know if you could, on-list or off-list. Thanks. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |