From owner-svn-src-head@freebsd.org Fri Aug 19 16:31:48 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 1606DBBF8EA; Fri, 19 Aug 2016 16:31:48 +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 E1E7E16CD; Fri, 19 Aug 2016 16:31:47 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7JGVYS7013718 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Aug 2016 09:31:35 -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> <86k2ff4cxs.fsf@desk.des.no> <86fuq24d8s.fsf@desk.des.no> <2f9fb04c-7ec4-be40-8fcb-0cf74bb56859@freebsd.org> <081362ef-ff4a-61d5-46e4-9a4cf8b699ee@freebsd.org> <880977BE-F00F-4188-A978-F292AB452C79@bsdimp.com> Cc: Warner Losh , Allan Jude , =?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: <16daa43f-fe4f-d191-b18f-da4ae3e690f5@freebsd.org> Date: Fri, 19 Aug 2016 09:31:34 -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: <880977BE-F00F-4188-A978-F292AB452C79@bsdimp.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVYrmu75wg1SZTo2Cfybe/4EHQ+tKEjyQsDtgDtuaOX2tXPvIg3zZA+WeTWl3LTT+tlOFXZLUu2gl6/djTC2DuQCGGD7gLJvsIM= X-Sonic-ID: C;VI7gZCpm5hGVEKDx2xNB0g== M;fEpCZSpm5hGVEKDx2xNB0g== 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: Fri, 19 Aug 2016 16:31:48 -0000 On 08/18/16 22:33, Warner Losh wrote: >> On Aug 18, 2016, at 11:21 PM, Nathan Whitehorn wrote: >> >> >> >> On 08/18/16 21:15, Warner Losh wrote: >>> On Thu, Aug 18, 2016 at 6:56 AM, Allan Jude wrote: >>>> On 08/18/16 05:50 AM, Dag-Erling Smørgrav wrote: >>>>> Nathan Whitehorn writes: >>>>>> OK. In which configurations? My Dell servers, for instance, don't do >>>>>> this. How are they set up? What drivers are being used? Is this >>>>>> something that affects passthrough disks, RAIDs, disk images? >>>>> Most LSI MegaRAID controllers don't have real passthrough, only JBOD. >>>>> You can query the drive with "camcontrol identify passX", but the >>>>> controller does not report a stripe size for the volume (mfidY). >>>>> >>>>>> The point is that *if the reported stripe size is wrong*, more things >>>>>> than partition alignment in the installer will suffer for it. >>>>> It's not wrong, it's non-existent, and I'm getting really tired of >>>>> repeating myself. >>>>> >>>>>> Fixing the installer with a bandaid in the run-up to a release is >>>>>> fine, but *we need to fix the underlying problem*. >>>>> We can't, because hardware sucks, and I'm getting really tired of >>>>> repeating myself. >>>>> >>>>> DES >>>>> >>>> Which makes more sense: >>>> >>>> A) If stripesize == 0, use some sane value like 4096 >>> I don't like this. >>> >>>> B) Some other combination that uses the reported stripe size, unless it >>>> is 0, in which case it uses 4096 (or some other value controlled by a >>>> different new sysctl) >>> Don't like this so much. >>> >>>> C) create kern.geom.min_stripe_size with a default of 512, but users can >>>> set 4096 if they use only 4k devices. (doesn't really solve the problem >>>> for the installer) >>> Default it to 4k, and allow users to set it to 512. If the drive >>> reports < this value >>> report this value instead. You'll need to make this a tunable. Then the upper >>> layers wouldn't care. There's a small chance that some SD cards might be >>> reporting values that are too large. But I think it is confined to SD cards and >>> if I see too many more I'll do something specific in the SD driver. >>> >>> Warner >>> >>> >> That sounds good to me and I think can clean up a lot of code and potential foot-shooting. Who is planning to make the patch? I'm happy to do anything that would be helpful. > The patch is super-easy, but I need to get the concept validated and make sure that it does not have unintended side effects. > > Warner > Sounds great. There is no urgency here -- we have a good solution for 11.0 already -- so taking time to do it right sounds good. I believe stripesize is only consumed by disk formatting tools, so unintended side effects at least should be minimal. -Nathan