Before an SSD sector1 was ever written to, it looks like all filled with zeros.
So, if I write all zeros to a sector, for the purpose of functionality, it will look just like a free one. Thus the controller has a technical possibility to treat it as such. My limited knowledge of IC architecture says that hardware-wise, slowdown from a circuit testing for all zeros would probably be negligible, if any at all.
The question is: does any flash/SSD controller actually implement this or anything similar?
It looks even more applicable to flash memory storage connected via interfaces that don't have the TRIM command, like USB.
In the answers posted so far, a few people outlined possible show-stopper issues. Yet they all turned out to be non-issues. Unless there's evidence those really are serious problems, please do not authoritatively claim they are but rather honestly say you're only hypothesizing that.
1A logical sector i.e. what the host sees.
Best Answer
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.