From owner-svn-src-head@freebsd.org Fri Aug 19 05:21:11 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 AC48ABBE3AB; Fri, 19 Aug 2016 05:21:11 +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 8F5E011AE; Fri, 19 Aug 2016 05:21:11 +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 u7J5L4wL010396 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2016 22:21:05 -0700 Subject: Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit To: Warner Losh , Allan Jude 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> 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: <081362ef-ff4a-61d5-46e4-9a4cf8b699ee@freebsd.org> Date: Thu, 18 Aug 2016 22:21:04 -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: 8bit X-Sonic-CAuth: UmFuZG9tSVaAVGTML+dYPQh1Or1JSc7OEKqc6YVveMKxkVEmIOUxXNT5gzDB0bI/PeH4Ia2xtpiCzxzNQg7WXO0RDYals0byGoo744SXVmo= X-Sonic-ID: C;hI6+ucxl5hG5EqDx2xNB0g== M;eIcmusxl5hG5EqDx2xNB0g== 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 05:21:11 -0000 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. -Nathan