What is the biggest stable memory overhead for SSDs?

Question

With an HDD, the largest overhead in accessing stable memory (where we measure access time from the moment the instruction passes the MEM stage in the pipeline) is the I/O costs for seeking the right track on the disk.

Overall, the contribution to time is probably something like this (I'm guessing, please correct me if I'm wrong):

Seek > Rotation > Copying to buffer > OS page replacement code
     > Actual bus I/O costs and copying to in-memory location
     > Context switches

I'm pretty certain about the first one, though.

What is the order for flash memory?

Answer 1

For the HDD case, your example looks pretty good. The average seek time is 1/3 of the maximum time to move across all of the tracks, and the average rotational delay is one half a revolution of the disk.

If the system has a multi-sector I/O buffer, then there will be a check whether the desired sector is already in memory, and if it is, then the existing copy will be used rather than reading it again off the HDD again. This is particularly true in those cases where clusters are used, and sequential sectors in the cluster are accessed.

On the other hand, if the sectors in a file are being read sequentially, but the sectors do not follow each other on the disk due to fragmentation, then you have the seek time plus rotational latency added to every sector read.

Also for the HDD case, there is normally very little difference between reading and writing (I realize you just asked about accessing the mass storage device, but I'm including this just to be complete). Even if the data is encrypted, there is a delay in unencrypting the data when reading, and encrypting it on writing, granted the latter could take a little longer.

For the SSD case, the big difference is there is no seek time or rotational latency. (There is some setup time, but it is in the order of 100 µs). Also, the transfer of bytes from the SSD memory to RAM can be several times faster then for a HDD. The overhead for an encrypted volume would also be the same as above.

The big hit with SSD is the writing of the data. NAND flash memory must be erased first, and then written in pages. The erasing can take a few milliseconds. Also, there is a finite number of times this erase cycle can be reliably performed on each page, so to keep the SSD media from wearing out too quickly, wear-leveling is used. This means a frequently written page of sectors will be moved to another area of the disk.

So to answer the question in your title, I would say the biggest overhead for SSD's would be the wear-leveling.

Answer 2

Unlike hard drives, where writing a sector causes old data to be written in the same location as the sector's previous contents, solid state drives invariable handle sector writes by storing data to a new location and then somehow making a note that the data should be found at the new location rather than the old one. A 32GB drive formatted with 512-byte sectors will need to track the position of roughly 64,000,000 sectors. Once upon a time, when drives were much smaller, some solid-state management systems simply marked each sector with its logical address and would either keep a mapping table in RAM or examine every sector when necessary to find a request, but neither of those approaches is practical when there are 64,000,000 sectors to track. Even if a drive could read a location data from one sector per microsecond, reading 64,000,000 would take over a minute.

I don't know to what extent any SSD makers publish the algorithms they're using for sector management, but it's possible to engineer in a variety of tradeoffs between random-access and sequential read speeds, random-access and sequential write speeds, RAM requirements, robustness in the face of adversity (such as unexpected power loss while writing), etc. Consequently, different chips may have substantial variations in average-case, best-case, and worst-case times for reading and writing. Specifications may offer average-case and worst-case performance figures, but I don't know in what cases one can guarantee that performance will be significantly better than the worst case (which would be much worse than the typical case).