Messages in this thread | ![/](/images/icornerl.gif) | | From | Linus Torvalds <> | Date | Tue, 11 Jul 2023 09:47:00 -0700 | Subject | Re: Fwd: Need NVME QUIRK BOGUS for SAMSUNG MZ1WV480HCGL-000MV (Samsung SM-953 Datacenter SSD) |
| |
On Tue, 11 Jul 2023 at 05:06, Christoph Hellwig <hch@lst.de> wrote: > > As far as I can tell Windows completely ignores the IDs. Which, looking > back, I'd love to be able to do as well, but they are already used > by udev for the /dev/disk/by-id/ links. Those are usually not used > on desktop systems, as they use the file system labels and UUIDs, but > that doesn't work for non-file system uses.
The thing is, the nvme code seems to actively do completely stuipid things in this area.
> And all this has been working really well with the good old enterprise > SSDs, it's just that the cheap consumer devices keep f*cking it up.
Christoph, deal with reality, not with what you think things should look like.
Anybody who expected unique ID's is frankly completely incompetent. People should have *known* not to do this.
"Those Who Do Not Learn History Are Doomed To Repeat It" - Santayana
and we have NEVER EVER seen devices with reliably unique IDs. Really. We've had these uuid's before (ask Greg about USB devices one day, and that was *recent*).
We've always known that vendors will fill in a fixed value, and somebody still decided to make this a correctness issue?
Christoph, don't blame vendors. Somebody did indeed f*ck up. But it was you.
> If we'd take it away now we'd break existing users, which puts us between > a rock and a hard place.
Well, here's a suggestion: stop making it worse.
For example, we have this completely unacceptable garbage:
ret = nvme_global_check_duplicate_ids(ctrl->subsys, &info->ids); if (ret) { dev_err(ctrl->device, "globally duplicate IDs for nsid %d\n", info->nsid); nvme_print_device_info(ctrl); return ret; }
iow, the code even checks for and *notices* that there are duplicate IDs, and what does it do? It then errors out.
Then expecting people TO WAIT FOR A NEW KERNEL VERSION when you noticed something wrong? What an absolute crock.
So stop blaming anybody else.
I think the code should *default* to "unreliable uuid", and then if you're sure it's actually ok, then you use it. Then some rare enterprise user with multipathing - who is going to be very very careful about which device to use anyway - can use the "approved list".
Or "Oh, I noticed a non-unique UUID, let me generate one for you based on physical location".
But this "my disk doesn't work in v6.0 and later because some clown added a duplicate check that shouldn't be there" is not a good thing to then try to make excuses for.
Linus
| ![\](/images/icornerr.gif) |