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

[Nathan Whitehorn]

On 08/17/16 08:03, Dag-Erling Smørgrav wrote:
> Nathan Whitehorn <nwhitehorn at freebsd.org> writes:
>> Dag-Erling Smørgrav <des at des.no> 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 <expletive>.

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