Can I emulate TRIM by writing all zeros?

Before an SSD sector¹ 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.

¹_{A logical sector i.e. what the host sees.}

ivan_pozdeev

Posted 2017-08-17T21:29:06.497

Reputation: 1 468

SSDs will wear out quickly if you write to every single sector. Each cell has a limited number of times that it can be written to, and after that the cell is too slow to be useful. If you have security reasons to "secure erase" the drive, then know that most SSDs are overprovisioned, so that there are physical cells left to spare. Thus, someone who can use a vendor utility to access every single cell might have access to data you thought was "securely erased". – Christopher Hostage – 2017-08-17T23:05:49.390

Sounds like you are asking whether some controller would do garbage collection by checking whether a logical block contains (to be less ambiguous, reads) all zero? (Like, auto-TRIM it if that's the case?) – Tom Yan – 2017-08-18T00:23:03.317

@TomYan It's even easier. It only needs to be checked on an incoming write command. If the data operand is all zeros, no writing is done and the logical block is unmapped instead. – ivan_pozdeev – 2017-08-18T00:28:00.813

1I've heard of controllers that would be smart enough to ignore zero filling after it exceeds certain contiguous length. I would assume (part of) the logical blocks would be in a state that is equivalence as TRIM'd. – Tom Yan – 2017-08-18T00:28:13.270

@TomYan I read that top gun SSDs (like Samsung PRO/EVO) compress data on the fly to achieve even faster read/write speeds - naturally, a chunk of zeros compresses really well. – ivan_pozdeev – 2017-08-18T01:16:46.237

"So, unless there's evidence those really are serious problems, answers authoritatively claiming they are (rather than only hypothesizing that) are not acceptable." - They are acceptable from a community perspective. They might just not answer your question. I caution you from using verbiage like "not acceptable", as a question author, you want as many people willing to write an answer as possible, negative verbiage can chase people who might know the answer to your question away. – Ramhound – 2017-08-21T15:50:09.773

I’m VTC as too broad because there are too many flash controller types. You need to seriously narrow down the scope of this question. Either way, Super User is not a research service. – Daniel B – 2017-08-21T15:55:43.860

@DanielB there are not so many distinctive techniques that SSDs use and they are typically mentioned in tech papers/reviews/etc. i.e. don't require firmware-level knowledge of specific models. Controllers only vary in details of their implementation which are of no concern here. – ivan_pozdeev – 2017-08-21T16:02:17.090

Answers

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.

LawrenceC

Posted 2017-08-17T21:29:06.497

Reputation: 63 487

Yet another non-issue. Since the described "special write" only affects the "LBA to PBA table", it doesn't matter that pages/erase blocks are larger than logical sectors - nothing would actually be written to NAND. The only problem is a block would have to be marked as "partially free" - but TRIM also accepts a set of logical block ranges (see https://stackoverflow.com/questions/3267244/ata-trim-specification/3267568#3267568 for a spec link), so the drive has to be able to cope with such a situation anyway.

– ivan_pozdeev – 2017-08-18T18:27:37.867

1I wouldn't put it past some crappy firmwares to actually write the 0's to the flash. You have no way of knowing what the firmware is doing unless you have the source code, compiled it, and installed it on the device yourself - or the firmware maker specifically warrants the specific behaivor. You might be able to discern true behavior by measuring timing of commands, though. – LawrenceC – 2018-05-06T20:31:54.690

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.

sawdust

Posted 2017-08-17T21:29:06.497

Reputation: 14 697

An erased sector is filled with bytes of 0xFF (all ones).? Then where comes RZAT in ATA and LBPRZ in SCSI? (where the Z is zero) – Tom Yan – 2017-08-17T22:55:08.610

@TomYan The zeroes that those commands return are not the result of reading the media. They are generated by the logic on the drive when you read "TRIM"d blocks. – Jamie Hanrahan – 2017-08-17T23:11:45.733

@TomYan -- Documentation for flash chips clearly state that the erased state is all ones. Documentation for SSD clearly indicate that the controller will respond with zeros for the data when that flag is set for a "free" (i.e. unmapped) LBA/sector. This does not mean that the LBA/sector actually contains zeros, since that would actually hinder performance (i.e. it's not erased and ready for a write). See the last paragraph of Section 3.8.2 of http://www.seagate.com/www-content/product-content/ssd-fam/1200-ssd/en-us/docs/100708406b.pdf

– sawdust – 2017-08-17T23:13:13.070

@sawdust see my comment in David Schwartz's answer. – Tom Yan – 2017-08-17T23:38:03.227

> and apparently your question is based on this faulty premise. You cannot be father from the truth. My question doesn't depend in the slightest on what exact pattern needs to be written. Also, by "appears to be filled with zeros", I mean that zeros are what is returned to the host - I'm pretty sure no (non-metadata) NAND reading is done in such case at all. – ivan_pozdeev – 2017-08-17T23:47:24.107

@sawdust Also, when it comes the logical block, if it reads zero, then it "contains" zero. That's why it was called "logical" block. – Tom Yan – 2017-08-17T23:48:21.750

@sawdust Finally, I suggested that such "writes" can be handled in a special way, without actually erasing/overwriting any (non-metadata) blocks. It almost looks like you didn't read into my post at all before replying. – ivan_pozdeev – 2017-08-17T23:53:37.550

Whenever a program wrote a sector of all zeroes... your scheme would allow the SSD to... handle it as an unmapped sector, instead of a sector in use and allocated to a file. Ever heard of sparse files? As long as the host reads from a specific logical sector exactly what it wrote to it earlier, it couldn't care less how the drive handles it internally. It's not like an unmapped logical SSD sector can suddenly start to contain something other that zeroes, is it? – ivan_pozdeev – 2017-08-18T00:19:25.730

1@ivan_pozdeev "As long as the host reads from a specific logical sector exactly what it wrote to it earlier, it couldn't care less how the drive handles it internally" -- Not true. I've worked on systems that have written zero-filled files to ensure that the sectors are accessible & allocated, i.e. to guarantee that (re)writing that file will not generate an "out-of-space" error. Note that "sparse" files should only be implemented at the filesystem level (which can define what is "not data"), and not at the storage device level. – sawdust – 2017-08-18T00:46:59.037

@sawdust Good point about "out of space". But not applicable to SSDs 'cuz they guarantee they're able to hold the entire advertised capacity of data all at once. I never proposed to use all the properties of sparse files such as the property to be able to be larger than the available storage. Only the property that the chunks that are all zeros don't actually need to be stored. – ivan_pozdeev – 2017-08-18T00:59:14.377

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.

David Schwartz

Posted 2017-08-17T21:29:06.497

Reputation: 58 310

2@RickBrant My point is, whether the physical sectors behind the scene are "one-filled" is out of the scope of the OP (neither do I think "one" is a good way putting it when you talks about the electronic level). What the OP needs to know is, the logical blocks read zero does not necessarily means any physical sector is freed. Otherwise he would naturally comes with question like, "can I emulate TRIM by one-filling". It was never about how a sector is filled but merely its state in the "logical block provisioning" sense. – Tom Yan – 2017-08-17T23:33:43.110

@TomYan I don't agree with you. He wouldn't come back with a question like that because he knows reading at trimmed sector returns all zeroes. As for it being out of scope of the OP, understanding the difference between physical and logical sectors is critical to understanding what TRIM is and does and why writing isn't a replacement for it. – David Schwartz – 2017-08-17T23:37:21.293

@DavidSchwartz I know how TRIM works. And exactly due to that, deduced a technically possible way to emulate it: such writes can be handled in a special way that does exactly what TRIM would do. – ivan_pozdeev – 2017-08-18T00:00:04.897

Trimmed sectors may not necessarily returns zero, not on all drives, that's why the RZAT/LBPRZ "bit" exists. It totally depends on the implementation of the TRIM on the drives. Sure it's a good thing to know what's the "reset" electronic state of a "SSD physical sector", but calling it one-filled and compare it against states on the logical block layer? I don't see how appropriate or correct it is. – Tom Yan – 2017-08-18T00:04:37.597

@TomYan -- "neither do I think "one" is a good way putting it when you talks about the electronic level" -- Raw flash that has been erased will read as all ones. – sawdust – 2017-08-18T00:17:12.820

"I know how TRIM works." - So why did you deduce if you fill the drive with 0's instead of 1's you would get what you want? – Ramhound – 2017-08-18T00:18:38.330

@Ramhound because Before an SSD sector* was ever written to, it looks like all filled with zeros. (*A logical sector i.e. what the host sees.) – ivan_pozdeev – 2017-08-18T00:32:04.787

@sawdust I never said it does not. The sentence you quoted was never about objecting that fact. It was about calling it "one(-filled)" is misleading, as if it is about writing ones to/through the logical sectors. That's why I prefer "reset", or whatever the "charge" is (positive/negative). More importantly, the "one-filled fact" doesn't matter here, because it would also be "one-filled" (electronic/physical sense) if you "one-filled" (logical sense, a.k.a. normal block writing) it, but it doesn't mean it is "unmapped" / "unused" / "trim'd". – Tom Yan – 2017-08-18T00:50:02.460