Card/USB flash storage: how to trim/discard/reset after heavy usage

Can I emulate TRIM by writing all zeros?

No.

Here's how flash works:

• Unwritten flash is all 1's, and writes pull down the 1's to 0's.

• Flash is written in a quantity of bytes known as a page, 2048 bytes being an example of a page size. (There is also a small amount of data - 64 bytes or so, that is also part of that page where ECC information can be stored)

• What if you want to change 0's back to 1's. You can't unless you erase the page.

• When you erase flash - which flips all the bits back to 1's if the page is not damaged, the quantity of bytes you can erase (the eraseblock size to borrow from Linux terminology) is typically bigger than the page size. 128k being an example of an eraseblock size.

• Erasing takes a lot more time than just writing to a page.

So, because:

• SSDs pretend they are standard hard drives to the host. Standard hard drives work on 512 byte sectors (called LBAs and numbered 0 to the capacity of the drive divded by 512), not 2048 or any other size;

• and the SSD firmware has to do a lot of fakery in the background since there really isn't 512 byte places to store the data like on a spinning hard drive;

• and writing to a page that doesn't need to be erased is faster than erasing it, then writing to it.

SSDs maintain something called an LBA to PBA table. The operating system, for example, tells the SSD to write to LBA 20, but it might really go into something like "Flash chip 2 page 56". This is maintained in the LBA to PBA table.

The SSD firmware will try to direct writes to fresh pages and avoid erasing unless necessary. If no unwritten pages are available, it will have to shuffle things around and do a read/maybe write somewhere else/eraseblock/write a bunch of stuff back cycle.

So the LBA to PBA table can be completely random.

TRIM tells the SSD that it can remove entries from this table (or mark as "LBA not written to yet") and actually erase some flash, and have it available for fast writes in the future.

So this is why writing all 0x00's or 0xFF's isn't equivalent. Only TRIM tells the firmware it's OK to not track things in that table and consider flash unused - and erase it in preparation for new writes.

Writing all 0x00's or 0xFF's results in a full LBA-to-PBA table that is tracking a data it thinks you are using and things will remain slow due to the need for it to shuffle things around and read/erase/rewrite.