The world of SSD drives is fast evolving. What started as a opaque replacement
of rotating rust in a SATA drive with flash soon became slightly
less opaque with addition of features like TRIM and we move have NVMe drives which dump HDD related semantics and offer significantly more performance.
But the world of SSDs is just beginning to evolve and efforts like our own Lightstor effort (www.lightstor.org, www.bitbucket.org/casl) indicate the myriad possibilities in the world of SSDs. While all drives get dumped under the rubric of SSDs, it is probably time to have some semi-formal taxonomy for the various types of drives.
So I propose the following (very unimaginative but functional) naming convention. I am also assuming the SATA interfaces are irrelevant going forward and hence do not have to be dealt with, teh assumption being that flash and its successors (SCM, NVRAM) will use some SERDES based IO/memory bus or DDR interfaces.
Type 1 drives are legacy NVMe drives. It may sound odd relegating NVMe to legacy status but that is how fast technology moves. The basis of legacy classification is that NVMe drives offer no functional difference from SATA drives. They are fundamentally about performance.
Type 2 drives are the newer class of NVMe+ drives. There area few proposals for the semantics, the FusinIO proposal, the latest OCZ drive proposal and the OpenChannelSSD proposal from ITU Copenhagen (https://github.com/OpenChannelSSD) . Drives in this category will support legacy NVMe modes but will provide enhanced modes to allow significant host control over their operations. With Type 2, the veil of opacity around a drive's functioning is finally lifted. This naturally has a lots of pros and cons and that will be the subject of another post.
Type 3 drives are drives offering memory semantics and the SNIA PMEM proposal is one of the proposed semantics for the functioning of such drives.
The various NVDIMM proposals also fall into this category. The fundamental
feature of a Type 3 drive is the absence of any I/O or storage semantics. They are just slower forms of memory (slower compared to DRAM) with some extra semantics to account for the higher latency of the underlying devices. See pmem.io for Intel's proposal based on the SNIA semantics.
Type 4 drives blur the notion of storage/memory and compute by supporting compute in storage. So apart from potentially supporting Type 2 and Type 3 semantics, they can also support compute offload mechanisms. The drive will present itself as another node in a distributed computing setup. Drives like these are inevitable in high I/O rate scenarios since the cost of moving bits across wires makes scaling very difficult. So compute and storage have to be co-located. Hadoop does the same thing on a large granular level, Type 4 drives will do it inside a single IC/card. The cores inside a type 4 drive can even be cache coherent with other CPUs in the cluster (as is planned in lightstor).
The above taxonomy should be not be interpreted as a hierarchy but merely seeks to clarify the different modes in which a an SSD can be operated. I had to come up with a preliminary taxonomy since our lightstor based drives operate ina ll the 4 modes and it was getting increasingly difficult to explain. Since drives of all the above 4 types exist today (Type 4 is albeit experimental), this taxonomy or something similar will hopefully lend some clarity when SSDs are analysed.
of rotating rust in a SATA drive with flash soon became slightly
less opaque with addition of features like TRIM and we move have NVMe drives which dump HDD related semantics and offer significantly more performance.
But the world of SSDs is just beginning to evolve and efforts like our own Lightstor effort (www.lightstor.org, www.bitbucket.org/casl) indicate the myriad possibilities in the world of SSDs. While all drives get dumped under the rubric of SSDs, it is probably time to have some semi-formal taxonomy for the various types of drives.
So I propose the following (very unimaginative but functional) naming convention. I am also assuming the SATA interfaces are irrelevant going forward and hence do not have to be dealt with, teh assumption being that flash and its successors (SCM, NVRAM) will use some SERDES based IO/memory bus or DDR interfaces.
Type 1 drives are legacy NVMe drives. It may sound odd relegating NVMe to legacy status but that is how fast technology moves. The basis of legacy classification is that NVMe drives offer no functional difference from SATA drives. They are fundamentally about performance.
Type 2 drives are the newer class of NVMe+ drives. There area few proposals for the semantics, the FusinIO proposal, the latest OCZ drive proposal and the OpenChannelSSD proposal from ITU Copenhagen (https://github.com/OpenChannelSSD) . Drives in this category will support legacy NVMe modes but will provide enhanced modes to allow significant host control over their operations. With Type 2, the veil of opacity around a drive's functioning is finally lifted. This naturally has a lots of pros and cons and that will be the subject of another post.
Type 3 drives are drives offering memory semantics and the SNIA PMEM proposal is one of the proposed semantics for the functioning of such drives.
The various NVDIMM proposals also fall into this category. The fundamental
feature of a Type 3 drive is the absence of any I/O or storage semantics. They are just slower forms of memory (slower compared to DRAM) with some extra semantics to account for the higher latency of the underlying devices. See pmem.io for Intel's proposal based on the SNIA semantics.
Type 4 drives blur the notion of storage/memory and compute by supporting compute in storage. So apart from potentially supporting Type 2 and Type 3 semantics, they can also support compute offload mechanisms. The drive will present itself as another node in a distributed computing setup. Drives like these are inevitable in high I/O rate scenarios since the cost of moving bits across wires makes scaling very difficult. So compute and storage have to be co-located. Hadoop does the same thing on a large granular level, Type 4 drives will do it inside a single IC/card. The cores inside a type 4 drive can even be cache coherent with other CPUs in the cluster (as is planned in lightstor).
The above taxonomy should be not be interpreted as a hierarchy but merely seeks to clarify the different modes in which a an SSD can be operated. I had to come up with a preliminary taxonomy since our lightstor based drives operate ina ll the 4 modes and it was getting increasingly difficult to explain. Since drives of all the above 4 types exist today (Type 4 is albeit experimental), this taxonomy or something similar will hopefully lend some clarity when SSDs are analysed.
Comments
Post a Comment