On 08/17/16 08:03, Dag-Erling Smørgrav wrote:
Nathan Whitehorn <nwhiteh...@freebsd.org> writes:
Dag-Erling Smørgrav <d...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
