I have two SSDs in a Raid0 stripe on my LSI1068E controller, and the resulting LUN is showing up as a non-SSD.

Is there a way to force this datastore to the SSD type?

I think that the "SSD vs. non-SSD" detection works only via VAAI enabled FC or iSCSI storage and not with local disks.

Anyway, you shouldn't be bothered ... I don't think that this will make a difference in performance, or are you not satisfied with the performance?

- Andreas

The performance seems ok. I'm just wondering if ESXi has any built-in handling to reduce the number of writes on SSDs to prolong NAND life. That, and ESXi should be able to tell the difference even when the disks are used to create a striped LUN on a supported SAS card.

Okay, here is how to do it:
http://www.virtuallyghetto.com/2011/07/ ... g-ssd.html

Anyway, it doesn't make much sense, because ESXi 5.0 does this differentiation only to identify SSDs for use with the new Swap-To-SSD feature. It does not use TRIM or other SSD-specific life extension measures.

Wow, that's surprising. You'd think by now they'd be on the SSD gravy train. When someone is looking at a $10K enterprise SSD, proper handling of write endurance becomes a major capital issue.

No, enterprise grade SSDs like the ones used in SAN storage arrays tolerate a whole lot more write cycles than consumer SSDs, and they have powerful wear leveling functions built into the firmware and do not really need TRIM support to enhance life time.

When using functions like SSD caching and auto-tiering to SSD that are built into the storage array the ESXi host (or any other attached OS) is not even aware of what physical media it is using for what, so it's not really up to the OS to care about SSD life time.

Well, first of all, even the newer eMLC flash only has about 3 times the write endurance of normal MLC flash. The newer 25nm NAND process is only good for about 2000 P/E cycles, so eMLC gets you back up to 6k in the same process size under that rule of thumb. And, the smaller the process size, the worse the problem gets.

Second, wear-leveling is just that - spreading the wear. It cannot solve the problem of excessive writes, which becomes an issue if those writes are unnecessary to begin with. Wear leveling actually increases the number of writes in favor of evening the wear across the NAND landscape. This makes failure of the drive come more quickly, but in a more predictable manner.

There is only so much a drive can do to protect itself from an OS that is clunky and disrespectful with its writes to disk. In many ways it is the responsibility of the OS to be aware of what it is doing and write responsibly.

Of course, what ends up happening is that the OS people and the Hardware people get into a pissing match over whose responsibility it is to design things correctly, the result being the horrible mess that the SSD market is today.

Highend enterprise SSD still uses 32nm SLC, some use eMLC, but they have 50% space reserved and write endurance is a few PB at least.

In a true enterprise environment, the SSDs are in RAID arrays on SAN and exported to ESX through block/NFS. They are fast, safe and they last long enough.

That may be true for existing deployments today, but as a technology, SLC is completely and utterly dead and has no future at all. The future of enterprise NAND storage is 18nm or smaller eMLC, which will support perhaps 2000-4000 P/E cycles depending on what write cycle process is used.

Lasting "long enough" is not good enough. Software vendors continue to ignore their responsibility to use resources wisely, including the very finite resource that is NAND P/E cycles. But, in general, software is 10 years or more behind hardware in its state of the art, so perhaps in another decade it will be common practice to use efficient data storage algorithms that are nicer to the underlying hardware.

I agree with you that vendors are trying all the ways to cut costs. However, if they can get eMLC cheap enough, they can put 100% or more reserve, plus controllers keep getting better.

Last long enough means more than 5 years. A typical storage system lifecycle is 5 years. In fact, only about 4 years, you need half a year to move data in and half a year to move data out.