Back in May SanDisk announced the X300s, which is the company's first SED (Self-Encrypting Drive). The X300s is based on the same Marvell platform as SanDisk's client drives but with the differentiation that the X300s is the only drive that supports encryption via TCG Opal and IEEE-1667 (eDrive) standards. Due to the encryption support the X300s is positioned as a business product since the main markets for encrypted drives are corporations and governments, which handle sensitive and confidential data on a daily basis.

In our Intel SSD 2500 Pro review I talked about the cost of a lost corporate laptop in more detail, but in short a lost unencrypted corporate laptop costs an average of $50,000 to the company through the loss of IP and data breaches. (Obviously not every lost laptop will cost that much -- some might not cost anything more than the hardware, but others could be far more valuable.) Encryption is the easiest way to minimize the loss because without access to the data in the laptop, the only loss is the physical laptop and the possible work hours as a result, but frankly that cost is only in the order of a couple of thousand dollars, whereas the loss of IP could result in millions of dollars in damage.

To provide the ease of encryption to everyone, SanDisk is including a license for Wave's EMBASSY Security Center with every X300s. While Windows 8 provides native support for hardware encryption through eDrive, most corporations are still using Windows 7 and that only provides software based BitLocker encryption. Moreover, eDrive has a rather strict set of hardware and software requirements, which can be a dealbreaker if dealing with older hardware with no UEFI and/or TPM support. In addition to Wave, the X300s has been certified by McAfee, WinMagic, Check Point, Softex, and Absolute for Opal encryption in case you or your company already has security software.

SanDisk X300s Specifications

Capacity

64GB

128GB

256GB

512GB

1TB

Form Factor

2.5" 7mm & M.2 2280

Controller

Marvell 88SS9188

Marvell 88SS9187

NAND

SanDisk 2nd Gen 64Gbit 19nm MLC

Sequential Read

510MB/s

510MB/s

520MB/s

520MB/s

520MB/s

Sequential Write

140MB/s

300MB/s

460MB/s

460MB/s

480MB/s

4KB Random Read

71K IOPS

85K IOPS

90K IOPS

92K IOPS

94K IOPS

4KB Random Write

37K IOPS

66K IOPS

80K IOPS

80K IOPS

82K IOPS

Idle Power (Slumber/DEVSLP)

90mW / 5.0mW

90mW / 5.0mW

90mW / 5.0mW

90mW / 6.0mW

95mW / 6.0mW

Max Power (Read/Write)

2.9W /
2.6W

2.9W /
3.6W

3.0W /
4.9W

3.1W /
5.0W

3.1W / 5.0W

Endurance

40TB (21GB/day for 5 years)

80TB (43GB/day for 5 years)

Encryption

TCG Opal 2.0 & IEEE-1667

The X300s is available in both 2.5" and M.2 2280 form factors. The 2.5" version comes in up to 1TB capacity and uses two different controllers depending on the capacity. 256GB and lower use the 4-channel Marvell 9188 (codename Monet Lite), whereas the 512GB and 1TB models use the full 8-channel Marvell 9187 controller (whose codename is surprisingly just Monet). The M.2 2280 is limited to 512GB due to form factor limitations and uses the Monet Lite controller for all capacities.

The PCB in the X300s is single-sided and features a total of eight NAND packages. It is quite impossible to see the markings on the chips from this angle due to the residue from the thermals pads, so here is a closer shot of the NAND with light coming from a better angle.

Unfortunately SanDisk's part numbers do not tell much and there is no public part number decoder available, but SanDisk told me that the X300s uses 64Gbit 1Ynm (i.e. second generation 19nm) parts, meaning that our 512GB sample features eight octal-die NAND packages.

Test Systems

For AnandTech Storage Benches, performance consistency, random and sequential performance, performance vs transfer size and load power consumption we use the following system:

That's too bad since it clearly has a piece of (undisclosed capacity) memory on the PCB. Looks to be a 128MB DDR2 chip. I wonder if any user data is stored in there of if it truly caches only the indirection table?Reply

The X300s does not have capacitors to provide power-loss protection as that is generally an enterprise-only feature. SanDisk does have a good white paper about their power-loss protection techniques, though.

There is only a handful of client-grade drives that provide power loss protection in the form of capacitors (Crucial M500, M550 & MX100, Intel SSD 730 & SSD 320 are the only ones I can remember).

The SSD 320 was never strictly a client drive as Intel also targeted it towards the entry-level enterprise market, hence the power loss protection. The SSD 730, on the other hand, is derived from the DC S3500/S3700, so it is basically a client tuned enterprise drive.

The power loss protection in the MX100 and other Crucial's client drives is not as perfect as their marketing makes you think. Crucial only guarantees that the capacitors provide enough power to save the NAND mapping table, which means user data is vulnerable to data loss. That is why the M500DC uses different capacitors because the ones in the client drives do not provide enough power to save all writes in progress.

SanDisk's approach is to use nCache (i.e. an SLC portion) to flush the NAND mapping table from the DRAM more often. The lower write latency that SLC has ensures that in case of a power loss, the data loss is minimal but it is true that some data may be lost. Crucial/Micron operates all NAND as MLC, which is why they need the capacitors to make sure that the NAND mapping table is safe.Reply

On the subject of mapping tables; how does controllers like sandforce (and some marvell implementations) work without DRAM ? Do they dedicate a portion of flash for that and how do they keep track of that portions activity (eg block wear) ?

Also, since some of the manufactures use pseudo SLC (ie MLC/TLC acting as SLC) how is endurance of those cells affected ? Can SLC portion last longer than normal MLC/TLC ?Reply

The controller designs that don't utilize DRAM use the internal SRAM cache in the controller to cache the NAND mapping table. It just requires a different mapping table design since SRAM caches are much smaller than DRAM. Ultimately the mapping table is still stored in NAND, though.

Pseudo-SLC can definitely last longer than MLC/TLC. With only one bit per cell, there is much more voltage headroom as there are only two voltage states.Reply

So really, MLC/TLC and SLC dies do not differ much internally. I'm guessing that real SLC just uses less on die error correction than MLC, but cells shouldn't be that different at all. Same i suppose goes for TLC aswell.

If this is the case, it brings an interesting question; If one were to buy MLC drive and wanted SLC grade endurace, it could (if access to firmware was available) tweak the firmware in a manner, so the whole drive would act as a pSLC; obviously at a cost of performance. Something like nCache 2.0, but expanded to whole capacity.

I believe some cheap flash drive controllers offered something like that using their MPtools. I remember messing around with a cheap TLC based flash drive; Once done, i ended up with 1/3 of the capacity, but write speeds increased dramaticly.Reply