From owner-svn-src-head@freebsd.org Wed Aug 17 15:27:13 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 65B6EBBC38D; Wed, 17 Aug 2016 15:27:13 +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 547D01F2C; Wed, 17 Aug 2016 15:27:12 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net ([128.54.117.176]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u7HFR0Tj010256 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 08:27:00 -0700 Subject: Re: svn commit: r304142 - head/usr.sbin/bsdinstall/partedit To: =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?= References: <201608150930.u7F9UL1V069576@repo.freebsd.org> <861t1n6749.fsf@desk.des.no> <581c856c-826b-529e-c9c6-a397fb679708@freebsd.org> <86wpjf4eun.fsf@desk.des.no> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Nathan Whitehorn Message-ID: <8cb3fa1a-50cb-e238-d006-b98a628d446d@freebsd.org> Date: Wed, 17 Aug 2016 08:26:59 -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: <86wpjf4eun.fsf@desk.des.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVauyAqj5D59L9d0QuN0zBMVNDOaOVZqi33i5R04TrQjZxWiMikqeUTfFdKKNYjKECq/OJ34p50jI2xIHmOQQl0AanFmcraZIEw= 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 15:27:13 -0000 On 08/17/16 08:03, Dag-Erling Smørgrav wrote: > Nathan Whitehorn writes: >> Dag-Erling Smørgrav writes: >>> [...] 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. >> And yet, if you look at the GEOM XML, it is reported and there. And, >> look, it's even right for the AF 512e disks in my machine! > Yes, that is one of the few cases where we get it right, as previously > mentioned. But it only works because it's known to us (listed in the > quirk table) and directly attached. If you replace that drive with a > brand new one a year from now, you have no guarantee that the new drive > will be recognized as an AF drive. Not true at all. All modern disks report their physical sector size, as distinct from the logical one, in their ATA IDENTIFY data and ata_da.c uses that. There is also a small quirks table for some older spinning disks and a few SSDs that lie and mostly hasn't needed additions in quite some time. camcontrol identify correctly reports 4096 for the physical sector size on 5 different random AF-512e disks I just checked (some of those are also, redundantly, in the quirks table). Since this seems to have become the standard, I can't imagine that the quirks table would need to grow much in the future for this issue. > >> I've literally never seen a case where we don't already do the right >> thing here. > The I can only conclude that you have very little real-world experience. > I have mentioned several examples to you, and even told you how to > confirm, by inspecting the source code, that most drivers do *not* set > the stripe size. Most drivers? Yes, sure. Most drivers that people use? No. And I am aware of how to use grep, thanks. > >> It's correct, as far as I can tell, 100% of the time on all possible >> variants of AF disks. > You keep repeating this, as if it somehow proves me wrong. It doesn't. > >> One could argue that calling this the "stripesize" is a hack, and I >> would agree, > One could, but one would be wrong. >> As for grepping, the CAM disk drivers are all in sys/cam, not sys/dev, >> as I'm sure you know, and you will find all the code that handles this >> there. > Only for directly attached drives, and most drives do not report the > correct physical sector size, which is why we have quirk tables. Which disks? Your original email said that VMware reports too-small values and that there is a bug in the LSI MegaRAID driver. I'm not sure which actual drivers those were (e.g. mfid or through CAM), or how they were set up (RAID or passthrough), but that's a small list and those issues can presumably be fixed. I would be happy to help make those changes if you can provide some more information. >> We should just fix the driver for whatever weird disk you have in your >> machine (what is it, by the way?). > Oh please. Now you're just being an . I somehow still don't know what problem, on what hardware, you are actually trying to fix. Instead, I get delightful personal invective. The patch is fine for 11.0. I would like to know what bugs it was fixing, so we can fix them more broadly after the release. Is that so much to ask? -Nathan > DES