From owner-svn-src-head@freebsd.org Wed Aug 17 10:09:18 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 2F5A3BBDDCF; Wed, 17 Aug 2016 10:09:18 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id ED0C7170C; Wed, 17 Aug 2016 10:09:17 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D11D72591; Wed, 17 Aug 2016 10:09:16 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 0854325F4; Wed, 17 Aug 2016 12:07:51 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit References: <201608150930.u7F9UL1V069576@repo.freebsd.org> Date: Wed, 17 Aug 2016 12:07:50 +0200 In-Reply-To: (Nathan Whitehorn's message of "Mon, 15 Aug 2016 08:04:26 -0700") Message-ID: <861t1n6749.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 10:09:18 -0000 Nathan Whitehorn writes: > As a note for people who weren't paying attention to the bug, we need > to fix this in a better way outside of the constraints of getting 11.0 > out the door. The system (gpart, the installer, ZFS, etc.) uses the > reported GEOM stripesize for partition alignment and IO block size > selection. If that is wrong, we should identify devices on which it is > wrong and fix them, and maybe also add some global tunable that sets a > floor on the numbers reported by GEOM_DISK. Hacking the installer like > this is triage, which is fine, but not viable as a permanent solution > to anything. Modifying GEOM to report a bogus number when none is provided by the lower layer(s) is absolutely not going to happen. You have absolutely no idea what your proposed change will break. And you keep refusing to address the fact that most drivers don't report a stripe size, except by repeating your claim that they do, with no evidence to back it up. Feel free to 'grep -r stripesize /usr/src/sys/dev'. Go on, I'll wait. Your contention that the installer does not make policy decisions is equally spurious. The installer makes many policy decisions, including the disk layout, the size of the swap partition, the name of the pool, the use of boot environments (which I dislike but am not allowed to override), the number of filesets and their mountpoints (which I also dislike and am not allowed to override either), etc. The Unix philosophy is to push such decisions up the stack, not down. The decision to align partitions on 4096-byte boundaries because we're not sure of the correct number but know for a fact that using a smaller number can have a huge impact on performance is the installer's to make. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no