From owner-svn-src-head@FreeBSD.ORG Mon Dec 6 21:49:13 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB087106566C; Mon, 6 Dec 2010 21:49:13 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id AE9F38FC08; Mon, 6 Dec 2010 21:49:12 +0000 (UTC) Received: by fxm16 with SMTP id 16so9875155fxm.13 for ; Mon, 06 Dec 2010 13:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bOXoQ0OggPKkxvr0842398cFDUFJqyN0M2bzzZPZQYg=; b=edelWFNaf6o4ojwzxd5MvcVoSZpKpV8zqUHIfbfqPFA7ulrx5/tKpdhHfJIKT9DgXh 0lOCOfmbbwqLihzNfwedpBL8S91zFTEg1kajFt1A0iIs8dlBXPKPiFLv9EhGH6xSGExP bFkEoyVS8fmKQywL8EW/UTIum/M3exfIdZrP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Xq5DtBgOpc45igwHBV0qjSs/q87tTpNBQXFFIuoyTVBET45O/aGuUKxxS38bX6PWmV PP3xtP4WDVDyVaORMyMaKEJPYXY7S+6f+R9vrb3mKY0bEGkr813ZIGKQR7BSI7LZxyYD LCOfNgXJG/iUZhMWk/7Ce8mzhCXGWYudOdupw= Received: by 10.223.72.202 with SMTP id n10mr6139678faj.74.1291672151628; Mon, 06 Dec 2010 13:49:11 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id o17sm1716697fal.1.2010.12.06.13.49.09 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 13:49:10 -0800 (PST) Sender: Alexander Motin Message-ID: <4CFD5A55.5030702@FreeBSD.org> Date: Mon, 06 Dec 2010 23:49:09 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101104 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <201012061218.oB6CI3oW032770@svn.freebsd.org> <20101206195327.GD1936@garage.freebsd.pl> <201012061518.49835.jhb@freebsd.org> <20101206211607.GA65110@muon.cran.org.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bruce Cran , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r216230 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2010 21:49:13 -0000 On 06.12.2010 23:22, Ivan Voras wrote: > On 6 December 2010 22:16, Bruce Cran wrote: >> On Mon, Dec 06, 2010 at 09:31:39PM +0100, Ivan Voras wrote: >>> For what it's worth, apparently linux has the concept of "physical" >>> and "logical" sector sizes (possibly in addition to "stripe size"), >>> with physical being 4096 and logical 512, for example: >>> >>> # hdparm -I /dev/sde | grep size >>> Logical Sector size: 512 bytes >>> Physical Sector size: 4096 bytes >>> device size with M = 1024*1024: 1430799 MBytes >>> device size with M = 1000*1000: 1500301 MBytes (1500 GB) >> >> So do we, except they're both the same for Advanced Format drives: > > There is a subtle difference here which may be important. We have the > concepts of "sectorsize" and "stripesize". It is only question of abstraction. As soon as any our disk device is GEOM abstraction - don't see reason why parameters should be specific. > I think camcontrol actually reports logical and physical sector sizes > as reported by low-level drivers but currently GEOM names "logical > sector size" as "sectorsize" and "physical sector size" as > "stripesize". `camcontrol identify` directly requests IDENTIFY data and parses them. There is nobody between it and the device. To see what GEOM receives from the disk driver use diskinfo. > The term "stripesize" can be overloaded to mean both the item in > question - 4 KiB physical sector sizes and RAID stripe sizes. I think > this situation is bad and that the two meanings should be split. There could be a long list of different "stripesize" sources. It is not a task of the partitioning tool or file system to know all of them. As I have described in previous email - only size matters. >> # camcontrol identify /dev/ada1 >> ... >> device model WDC WD10EARS-00Z5B1 >> ... >> sector size logical 512, physical 512, offset 0 > > Agreed. Some drives lie. "Everybody lies". :) If Linux example was taken from page I've seen - it was external WD USB storage somehow reporting that physical sector size, not the disk itself. I haven't seen proper reporting in any WD drive yet (started to think about adding quirk at ada driver). Now waiting for Seagate 4K disks reports to check how bad things are. -- Alexander Motin