SSDs and TRIM on the Raspberry Pi

[jimrh]

Viz.:

Raspberry Pi-5?

TRIM is an important maintainance feature for solid-state media as it helps the internal “garbage collection” routines know what’s fair game and what isn’t. If you remember, solid state media is organized into three logical groups: Read blocks. Read blocks are the smallest logical grouping of data.  Read blocks represent the physical “sector size” of the flash media and is the smallest amount of data that can be accessed at a time. Write blocks. Write blocks are a very large group of r…

 

Rather than dilute other threads, I am starting a thread on the topic of solid state media and TRIM.

As I mentioned in my previous post:

TRIM is one way that the operating system can tell the device which blocks of data are no longer valid at the OS level, allowing the controller logic to proactively collect blocks that are candidates for being discarded. If the OS marks a block as “discarded”, the SSD knows that the block doesn’t have to be preserved during erasure.

Why TRIM?

Magnetic media devices, particularly hard drives, can read, write, erase, or whatever at the sector/cluster level, completely independent of any other sectors or clusters elsewhere on the device.  In essence, they are mechanical, persistent RAM.

The physical device doesn’t have to manage garbage collection, (aside from reallocating bad blocks), as that’s entirely within the operating system’s control and authority.

The operating system manages the volume bitmap, the “deleted” flag on directory items, cluster file links, etc.  As far as the media device is concerned, all it does is follow instructions - go hither and yon, and do something.

Magnetic media is changeable at the micro-level.

On the other hand, solid state media is fundamentally different.  Instead of storing data as easily-changed magnetic domains on a surface, solid state media stores data as trapped charges that are “injected” into an isolated gate buried within a silicon substrate.

Because they’re “injected”, (requiring relatively high amounts of energy to trap the charge), they cannot be “un-trapped”.

Actually, they can, but it’s not easy.

Early solid state devices, (EPROMs), used high energy ultraviolet light to allow the trapped charges to bleed away.

Later devices (Electrically Erasable PROMs or EEPROM devices), could be erased by a special, higher voltage signal that would discharge the trapped charges.  (CMOS firmware chips are common examples of this.)

The problem with all of these was that it was an “all or none” arrangement. When you erased the device, you erased the ENTIRE device.  If you had to update five bytes of data, you had to nuke and reprogram the entire device from start to finish.

“Flash” devices introduced the ability to modify localized domains within the device, but there was a “quid” to be paid for that “pro-quo” - the flash devices was, essentially, a collection of EEPROM devices on the same die.

Now, that’s not exactly true, but it’s close enough to make the point.

An “erase block” is roughly the equivalent of an individual electrically erasable device with smaller writable domains within it.

As a consequence, erase blocks are huge, many megs in size.

Since only an entire erase block can be erased to prepare it for re-use, management of them becomes a major task and non-trivial amounts of programming logic are devoted to it.  SSD’s and flash devices have entire processors and miniature operating systems installed just to manage the memory.  A recent tear-down, (un-encapsulation), of a SSD showed a large-scale ATMEL processor running the show within it.

So, it’s important to understand the significant architectureal differences between magnetic media and solid-state media.

[jimrh]

Chapter 2:
So, what’s the big deal?

If you remember from the first chapter, solid state devices used a “trapped” charge (an isolated MOSFET gate), to program a bit of data.

Silicon, (despite what the marketing mavins tell you), isn’t eternal.  Especially if you keep beating it senseless injecting and depleting charges over and over again - the silicon develops leakage paths and the trapped charges fade away.

This, by the way, is why solid-state media has a limited number of write cycles.  And, just in case you didn’t notice, an “erase” is simply another kind of “write” and it results in increasing wear and reduced lifetime.  The only difference is that it affects a much larger amount of the device at a time.

Translation:
Write/erase cycles are bad.

Corollary:
Anything you can do to reduce the number of write or erase cycles is A Good Thing.

This brings us to the magical world of TRIM.

[jimrh]

Chapter 3:
What is TRIM and why is it important?

Going back to chapter 2, we discovered that any kind of write cycle, (including erase cycles), reduces the lifetime of the solid-state device.

In the case of magnetic media, the device was essentially data agnostic.  It didn’t care what the data looked like, where it was stored, or how it was managed because reading and writing weren’t really different regarding media lifetime.

Solid-state devices on the other hand, need to be very aware of the status of the data to reduce excess stress on the media.

For example:

• Assume an erase block contains a number of “discardable” (invalid), write blocks and some that are not marked as “discardable”.

• Also assume that the operating system considers ALL the blocks in that section invalid, but can’t tell the device.

Therefore, if the solid-state device needs to erase that block, it has to move all the data that the OS doesn’t care about, wasting multiple write blocks to move useless data that didn’t need to be moved.

Now let’s try another example:

• Assume an erase block contains a number of “discardable” (invalid), write blocks and some that are not marked as “discardable”.

• Also assume that the operating system considers ALL the blocks in that section invalid, but in this case it CAN tell the device that the operating system considers those blocks discardable too.

The result is that the SSD doesn’t have to preserve, and move, any of the data.  It’s faster and drastically reduces the number of write cycles performed.

That, my friends, is TRIM.  TRIM allows the overriding operating system to help coordinate with the solid-state device’s own efforts and reduce wear on the device.

TRIM provides a “back-channel” way for the OS to communicate with the underlying device so all discarded blocks are properly accounted for.

[jimrh]

Chapter 4:
If TRIM is so hot, why isn’t it universal?

Great question.

It should be and, perhaps in the future, it will become so.

Part of the problem is market pressure, especially on “throw-away” media devices and SD cards.  Since a flash drive or SD card will, likely, become obsolete (because it’s too small), long before it fails it doesn’t make sense to implement TRIM on removable media.

Also, removable media is usually “read mostly”, being used to store something - like the floppy disks of old - that is primarily going to be read, not written.  Because of this, TRIM on removable media, (SD cards and USB media), hasn’t been all that necessary.

Except. . . .

The advent of micro-sized computers that use “removable media” as their primary mass storage device, makes it necessary to re-think TRIM on removable media.

The good news:

• Many reputable media manufacturers, (like Toshiba, SanDisk, Seagate, and others), recognize the need for external SSD’s to support TRIM.

• More important, they design the USB interface to expose the more advanced command modes so that TRIM can be enabled and used.

The bad news:

• SD cards are still considered “throw-away” storage, even though capacities are becoming huge.

• Less scrupulous manufacturers ignore specifications, or interpret them rather loosely as suggestions rather than requirements.

• However there is hope as some manufacturers are beginning to implement TRIM, so that persistent mass storage on SD cards can begin to benefit from TRIM.

[jimrh]

Chapter 5:
Do I need TRIM?

The correct answer is “it depends”.

• Do you use solid-state media as persistent mass storage for extended periods of time?

• Do you run operating systems, or other high-write-pressure applications from the device

• Do you often completely re-install or re-write the entire device?

• Or, do you use it as a pluggable read-mostly memory device, as if it were a solid-state CD-ROM?

If you’re using it as a solid-state CD-ROM or a read-mostly device, the answer is no.  You don’t need TRIM on that device.

However, if you are running the device as a system’s main storage device, or are using it in an environment that has a high write-pressure to the device, TRIM can save you precious write cycles and help speed up the device.

What say ye?