I totally agree. I'd love to see the quantification of what is "bad" about mislabeling. Nobody seems to know that, and I think that is very important to the discussion.
Well, it's pretty simple. First, I'm pretty sure we can agree that there's a broad spectrum of storage speeds. For purposes of rational discussion let's keep it realistic and avoid "tape drives" and "PCIe NVMe based SSD" at both ends - redundant storage required. ESXi required. So, storage options there probably range from the low end, a FreeNAS box with a mirror of two hard drives at 10% capacity presented over iSCSI, all the way on up to a nice LSI 3108 attached to a pair of Intel S3710's as direct attached storage.
SIOC thresholds and other storage policies for SSD datastores are naturally going to be configured to assume that SSD storage is faster than HDD storage. I think we can agree that there's a lot of fuzzy; I'm busy making a very fast HDD storage array, and you can definitely have a hella slow SSD array, but generally speaking, I would expect "SSD" to mean "capable of sustaining significantly more IOPS than HDD". My very fast HDD storage array will be sized to accommodate the working set, so for all the blocks likely to be accessed regularly, I'd expect it to appear "like a SSD" because it's being served out of ARC or L2ARC. But I whomp right into really slow speeds the instant I touch pool (partly because the pool's only a few disks right now). Things like SIOC are intended to guarantee fair access to storage. Things like ARC and L2ARC are bonus speed turboboosters, but if a bunch of VM's decide to wander outside the working set, then we get really bad things going on. This horribly breaks configured policies.
Don't have policies or thresholds?
All hell would break loose if someone didn't recognize that the device in question wasn't actually SSD and enabled swap to host cache on it. I'm sure that someone will respond with "but that'd never happen because you'd KNOOOOOOOOOWWWWW (whinyvoice)". The problem is, in IT, that's not always the case. I spent a year doing low level development work on a major IT infrastructure project without ever once laying eyes on the gear in question. It is completely normal for there to be compartmentalization in the IT realm, where the virtualization guys ask the storage guys for "some more space," and get handed an iSCSI SAN login. This kind of mislabeling is a great way for further mistakes to be introduced into the environment.
Now, I've very patiently explained this several times. This discussion is like the ECC discussion. You can't PROVE to me that ECC matters either, yet you know in your head that the position is defensible and correct. Right now the people who accuse of "handwaving" - including you - are playing the side of the non-ECC defender who has yet to SEE a firsthand example, and so refuse to believe that it's an issue.
It's an issue. It may not be a pool-shattering issue, but it's an issue.
The conservatism in me says "label it properly" or "label it as non-SSD all the time". After all, ZFS creates its own performance problems when under-resourced, so it's totally possible to have an all-SSD pool that performs worse than a platter-based pool.
The realist in me says that if iXsystems has talked to VMWare and they say to mislabel it as an SSD, then why not?
And people I talked to at VMware, and other storage professionals, all went "that's wrong."
If VMware wants to post a statement from engineering that officially sanctions this, that's one thing. There's a nice knowledgebase service they have and I'll buy it when someone posts the KB number that indicates VMware thinks this is fine.
Until then, I'm going to have to assume that maybe something might have been said by someone who wasn't qualified to make the statement, or was making a much more narrow statement (maybe like "tagging an iSCSI device as SSD will cause UNMAP/TRIM to function as you need"), or maybe misunderstood something.
Further, I'm not hearing compelling technical arguments
for this tag to be applied, and it clearly violates POLA as a number of people have come forward to raise the issue. So now I'd like to turn the tables and invite Jordan, or whoever is in favor of this at iX, what the reasoning is. There's been a huge void where that explanation could be, and - speaking at least for myself - I'm happy to listen to technical arguments and try to understand the reasoning behind things.
But even the suggestion that this could be a configurable option in the iSCSI configuration, which seems a very reasonable compromise, was rebuffed.
In any case, it's clear to me that iX isn't interested in addressing the issue, so I'm going to close the thread. If Jordan wants to come and discuss the technical merits of labeling this as SSD, he's of course able to reopen it for further discussion.
