svn commit: r304142 - head/usr.sbin/bsdinstall/partedit

Warner Losh wlosh at bsdimp.com
Fri Aug 19 05:33:40 UTC 2016


> On Aug 18, 2016, at 11:21 PM, Nathan Whitehorn <nwhitehorn at freebsd.org> wrote:
> 
> 
> 
> On 08/18/16 21:15, Warner Losh wrote:
>> On Thu, Aug 18, 2016 at 6:56 AM, Allan Jude <allanjude at freebsd.org> wrote:
>>> On 08/18/16 05:50 AM, Dag-Erling Smørgrav wrote:
>>>> Nathan Whitehorn <nwhitehorn at freebsd.org> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20160818/0da81154/attachment-0001.sig>


More information about the svn-src-head mailing list