I've heard from a source that the reason it takes so long to copy media to the iPhone is flash's slow write speeds. I mention this because the relatively slow write speed of flash can be a bottleneck in certain circumstances, even though write operations are typically "fire and forget." A new technology from SanDisk, however, claims to boost flash's random write speeds by up to 100 times under certain conditions. SanDisk is also proposing two new metrics that the company feels will help customers compare flash to magnetic storage alternatives.

Write faster

SanDisk's new ExtremeFFS aims to address write speed issues using a version of the TrueFFS technology that the memory maker acquired when it bought M-systems, a flash technology company. To understand how ExtremeFFS works, you first need to know more about flash's write limitations.

More recent flash versions have much-improved write speeds, but NAND flash will always be challenged in this regard because the way that writes work with the technology. Specifically, in order to write data to a nonempty flash sector, you must first erase that sector and then write to the newly empty spot. This erase-before-write requirement means that on a basic level, flash writes are slow because they often take two operations to complete.

The problem is worse for random writes than it is for streaming writes, because a single erasure of one large section of storage can accommodate a batch of multiple writes; contrast this to random writes, where each individual write must first be preceded by an individual erase.

In addition to the erase/write issue, which I've actually oversimplified here, flash's speeds are also affected by the amount of software that it takes to actually manage the physical aspects of the technology. In a nutshell, most operating systems and filesystem drivers expect for a mass storage device to be structured like a hard disk, i.e., addressable using cylinders and sectors. Flash, however, is arranged in the typical RAM grid structure, which means that on a basic level there must be a mechanism for mapping the OS model of filesystem locations onto the physical flash hardware.





The general concept also applies to ExtremeFFS TrueFFS mapping, from a whitepaper on the topic.The general concept also applies to ExtremeFFS

In the case of ExtremeFFS, this OS-to-physical mapping is not static. Rather, the controller and software work with the flash to do dynamic mapping, so that related file blocks are clustered together for maximum streaming read performance, and random erase/write operations are distributed based on a number of reliability and performance factors. In regard to the latter, random writes can be cached and then actually written to the disk at the optimal time and location in order to cut down on the number of erases per write.



The TrueFFS stack, again applicable to ExtremeFFS

ExtremeFFS can also do a few more tricks, like doing housekeeping and garbage collection chores (marking bad blocks and actually erasing blocks marked as "empty") simultaneously with regular reads and writes. Finally, the software can learn a user's data access patterns, so that data is eventually arranged for maximum efficiency.

This latter feature—the user pattern learning—seems like it will be especially hard to pick up with benchmarks, and SanDisk's press release acknowledges as much. But if it works, there has to be some way to measure it, so I'm anxious to get our hands on one of these drives and see if we can quantify the effect.

New metrics

SanDisk is concerned that the current crop of hard drive-oriented metrics by which consumers judge storage devices are ill-suited to SSDs, and I happen to agree. However, I'm not entirely sure that the two new metrics that the company has proposed are what the doctor ordered.

Both of these "metrics" aren't really metrics as much as they are "ratings," like AMD's erstwhile Performance Ratings. In performance case, the rating is "vRPM," for "virtual revolutions per minute," and it's an attempt by SanDisk to say "this is how fast you'd have to spin a hard drive to get this same level of performance." The vRPM rating is by plugging an SSD's read operations per second and write operations per second into a formula, which spits out a fake RPM number.

If this sounds kind of contorted and pointless, that's because it is. Hard drive RPMs are only a general proxy for relative drive performance, so it's not at all clear why anyone would want to take actual performance data (ops per second measurements) and then convert it into a number that's a proxy for the performance of a different type of device. But this is what SanDisk proposes to do. (Good luck with that.)

The company's second proposed rating is called long-term data endurance (LDE), and it represents an attempt to quantify for users how much data can be written to a device over the course of its lifetime. The basic LDE unit is "terabytes written," or TBW, so that the owner of an SSD with an LDE of 40TBW can expect to be able to write up to 40TB of data to it before it's worn out.

By way of example and justification, SanDisk's LDE whitepaper contains the following quite telling quote:

If a user has some idea of how many GBs/day he writes on the average, he can estimate the actual usable lifetime for him from dividing LDE by his average daily usage. For example, if a drive has a LDE of 40TBW and the user writes 10GB per day, then LDE is not exhausted in the first 10 years.

Raise your hand if you have even a ballpark idea of how many GB per day you write to your hard drive. I thought so.

Still, in spite of the fact that this LDE rating appears to be relatively worthless, it has the distinct advantage of appearing to be informative and important. I mean, who doesn't want to be able to write more terabytes, even if they have no idea how many they're writing today? For this reason, I give LDE better odds of success than vRPM, and it may become the MTBF of the SSD world. (Before you write in, I know that MTBF numbers are made up and generally pointless, which was the point of equating them with LDE numbers.)

Further reading