2

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.

ivan_pozdeev
  • 1,897
  • 18
  • 34
  • 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 Aug 17 '17 at 23:05
  • 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 Aug 18 '17 at 00:23
  • @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 Aug 18 '17 at 00:28
  • 1
    I'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 Aug 18 '17 at 00:28
  • @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 Aug 18 '17 at 01:16
  • "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 Aug 21 '17 at 15:50
  • 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 Aug 21 '17 at 15:55
  • @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 Aug 21 '17 at 16:02

4 Answers4

3

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
  • 73,030
  • 15
  • 129
  • 214
  • 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 Aug 18 '17 at 18:27
  • 1
    I 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 May 06 '18 at 20:31
2

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.

Thomas Guyot-Sionnest
  • 1,271
  • 13
  • 14
1

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.

Community
  • 1
sawdust
  • 17,383
  • 2
  • 36
  • 47
  • `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 Aug 17 '17 at 22:55
  • 1
    @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 Aug 17 '17 at 23:11
  • 3
    @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 Aug 17 '17 at 23:13
  • @sawdust see my comment in David Schwartz's answer. – Tom Yan Aug 17 '17 at 23:38
  • _> 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 Aug 17 '17 at 23:47
  • @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 Aug 17 '17 at 23:48
  • @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 Aug 17 '17 at 23:53
  • _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](https://en.wikipedia.org/wiki/Sparse_file)? 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 Aug 18 '17 at 00:19
  • 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 Aug 18 '17 at 00:46
  • @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 Aug 18 '17 at 00:59
  • This answer confuses sectors (as seen by the host side) and flash blocks (as seen by the flash controller on the stick). While erased (nand) flash reads back as all 1's, this has nothing to do with sectors presented to the OS. For the OS side, an unmapped sector and an all-zero sector are the same (other than possibly speed of access), and will not cause issues as wrongly claimed by this answer. Sparse files are a completely different concept and should not be mixed into this discussion - both mapped and unmapped sectors can cause a flash drive to run out of (internal) storage space. – Remember Monica May 28 '23 at 05:24
0

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
  • 61,528
  • 7
  • 100
  • 149
  • 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 Aug 17 '17 at 23:33
  • @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 Aug 17 '17 at 23:37
  • @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 Aug 18 '17 at 00:00
  • 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 Aug 18 '17 at 00:04
  • @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 Aug 18 '17 at 00:17
  • "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 Aug 18 '17 at 00:18
  • @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 Aug 18 '17 at 00:32
  • @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 Aug 18 '17 at 00:50