Can I emulate TRIM by writing all zeros?

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.

Can I emulate TRIM by writing all zeros?

No.
The act of writing requires an erased sector, and then the actual write operation occurs.
The write operation is an indication to the SSD that this sector is in use (the opposite condition that you want with a real TRIM command).

Before an SSD sector was ever written to, it looks like all filled with zeros.

Incorrect, and apparently your question is based on this faulty premise.
An erased sector is filled with bytes of 0xFF (all ones).

A format traditionally writes all zeros to every sector.

So, if I write all zeros to a sector, for the purpose of functionality, it will look just like a free one.

No, it will not.
Beware that there are "free" sectors at the filesystem level, and "free" sectors at the SSD level. In theory they should be the same set, but since the SSD has to be explicitly informed by the filesystem that a sector is "free" (with a TRIM comand), there are discrepancies.

ADDENDUM

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?

No, because that would lead to unintended data loss.
Whenever a program wrote a sector of all zeroes (e.g. a memory image can have such blocks), your scheme would allow the SSD to discard that sector, since it would handle it as an unmapped sector, instead of a sector in use and allocated to a file.

Bottom line, your proposed scheme (using data content) does not work.
If you want to designate a sector as free or unused, then there's the TRIM command.
There is no substitute write operation.

Actually, an erased SSD sector is filled with ones, not zeros. You are confusing SSD sectors (the actual physical sectors on the SSD that we want to trim) with disk sectors (the logical sectors the SSD presents to the file system after it's done with its management magic). Filling logical sectors with zero would untrim since it would force the SSD to allocate erased physical SSD sectors and fill them with zeros.

When a logical sector is trimmed, the SSD unmaps any physical sectors mapped to that logical sector. When it gets a chance, it erases them, which fills them with 1's. Once erased, they're added to a pool of erased physical sectors. The goal of trimming is to enlarge the pool of erased physical sectors.

When you read a logical sector that has no corresponding physical sector, the drive returns a page of zeroes. But it doesn't have to read any physical sector to do so, nor could it since no physical sectors are mapped.

See here for more details.

The short answer is likely not, and if you can do that it would be only because your controller explicitly detects zeroed blocks and trim them (I'm not even sure if any controller does this but afaik some VM implementation can detect zeroed blocks and trim them on the host OS).

All previous answers talk about flash format and the fact it starts with all bits set to 1's, but that is completely besides the point. Most controllers will return all zeros for trimmed/unallocated blocks (not all of them guarantees it IIRC!) and so the idea is that if you write 0's to a block, the controller might be able to detect it and trim the block rather than allocating and saving it.

I don't think there can be a clear No answer without looking at all major controller firmwares and see if any implement this feature, but if a controller can implement it without noticeable overhead it's definitely a plus as zeroed blocks will both be faster to write and extend the disk's life expectancy, not just with the saved block write but also by leaving more free blocks for wear leveling.