From owner-svn-src-head@freebsd.org Wed Aug 17 18:00:28 2016 Return-Path: Delivered-To: svn-src-head@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 33FA6BBD95B; Wed, 17 Aug 2016 18:00:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 16D0E199B; Wed, 17 Aug 2016 18:00:27 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([169.228.189.36]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7HI0L49005836 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 11:00:21 -0700 Subject: Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit To: Andriy Gapon , 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> <445700cb-c4b4-9272-df17-a851a6200543@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: Date: Wed, 17 Aug 2016 11:00:20 -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: UmFuZG9tSVYFIqqtA+yJncLr5Or0QwCYVKjmrfBlc9pzSgMAArO9tTOHCI7G34u7CIZR0VDDz/SsDfULAI0+GYGruHbj8cS2nvNzrZB44iE= X-Sonic-ID: C;BB+2dqRk5hGmWKDx2xNB0g== M;kGj+dqRk5hGmWKDx2xNB0g== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 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: Wed, 17 Aug 2016 18:00:28 -0000 On 08/17/16 10:56, Andriy Gapon wrote: > On 17/08/2016 19:36, Nathan Whitehorn wrote: >> 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? > It would be perfect to get a correct description of a disk and to do that in > central place. But still I, as a user / administrator, want to be able to > _force_ the alignment that I want when I partition a disk, create a filesystem, > etc. That is, even if the kernel reports the perfectly correct information and > the tools know how to automatically do what's best for me, I still want to eb > able to override. And I think that installers and administrative tools should > provide a way to do that. And many already do, e.g. 'gpart add -a X'. > So, I do not see how striving for the better disk detection (in a central place) > and having more knobs in the administration tools are mutually exclusive or > conflicting goals. > > Just my two bits. Agreed 100%. The issue here is that this kind of patch unconditionally overrides the kernel in an unsettable way. I think the right scheme is: 1. Try to get the real values as much as possible. 2. Provide a global hint to all tools that you want some value (e.g. 4K) unless the drivers are *sure* it's the wrong answer. 3. Have options in individual tools to force other values. We have (1), though it can probably be improved, and (3) and just need (2). -Nathan