From owner-svn-src-all@freebsd.org Wed Aug 17 16:36:17 2016 Return-Path: Delivered-To: svn-src-all@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 73C11BBDFF1; Wed, 17 Aug 2016 16:36:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E2DE190A; Wed, 17 Aug 2016 16:36:17 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([169.228.189.36]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7HGaCAs026713 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 09:36:13 -0700 Subject: Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit To: Warner Losh References: <201608150930.u7F9UL1V069576@repo.freebsd.org> <861t1n6749.fsf@desk.des.no> <581c856c-826b-529e-c9c6-a397fb679708@freebsd.org> <86wpjf4eun.fsf@desk.des.no> <8cb3fa1a-50cb-e238-d006-b98a628d446d@freebsd.org> Cc: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Nathan Whitehorn Message-ID: <445700cb-c4b4-9272-df17-a851a6200543@freebsd.org> Date: Wed, 17 Aug 2016 09:36:12 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaNaPsK1U2+5Er4m0/6y4VC+uZX4higp+OnDJSIsGNtmD4TzmkNfLifRmuQbCpgLDvyKNm7IAk+q0U6Wk83UCTSsL1RBki5VNY= X-Sonic-ID: C;zlvRtZhk5hGvua/hcgQksw== M;UJz6tZhk5hGvua/hcgQksw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 16:36:17 -0000 On 08/17/16 08:57, Warner Losh wrote: > On Wed, Aug 17, 2016 at 9:26 AM, Nathan Whitehorn > wrote: >> Not true at all. All modern disks report their physical sector size, as >> distinct from the logical one, in their ATA IDENTIFY data and ata_da.c uses >> that. > You are correct that there are two fields in the ATA IDENTIFY. However, > you are incorrect in thinking that all modern disks report their actual > physical sector size instead of a 'compatibility' number. We have dozens > of quirks and are adding them at the rate of a couple a month to make the > current imperfect magic happen. > >> There is also a small quirks table for some older spinning disks and a >> few SSDs that lie and mostly hasn't needed additions in quite some time. >> camcontrol identify correctly reports 4096 for the physical sector size on 5 >> different random AF-512e disks I just checked (some of those are also, >> redundantly, in the quirks table). Since this seems to have become the >> standard, I can't imagine that the quirks table would need to grow much in >> the future for this issue. > Any yet the table continues to grow. As someone who evaluates disks for a large > streaming media company, you cannot begin to imagine the number of things > that vendors get wrong... Life would be so much easier if you could actually > trust vendors to report things correctly in their ATA IDENTIFY command. > SCSI is better, but still not perfect. > > You should really listen to people that have been on the front line here. > CAM does a decent job of getting things right. It isn't perfect and can never > be perfect. Expecting it to magically change to be perfect is unreasonable > and will literally never happen. > > Warner > OK, so then what is the solution here? We have a number of tools that need to know this information: gpart, sade, bsdinstall, zfs, graid, etc. If we want to have a consistent set of defaults -- for example, to use 4K across the board, which I think is a good idea -- there should be a central place to set this that does not involve hacking a variety of independent tools. Do you disagree? I don't care how that happens. It happens that the way we currently encode this is geom stripesize. If we feel like we can't get this right in drivers, then we should provide a tunable to set a minimum default alignment. You could implement this in lots of different ways. But having static values hardcoded in random places that makes similar tools (sade, gpart) behave inconsistently cannot possibly be the answer. This is my point, from beginning to end. Is there any reason -- at all -- that we should prefer per-tool one-off changes to fixing the central mechanism we already have to give consistent results that we think are reliable? -Nathan