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.

  • 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 0: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 0: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 0: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 1:16
2

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.

|improve this answer|||||
  • 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 stackoverflow.com/questions/3267244/ata-trim-specification/… 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 6 '18 at 20:31
1

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.

|improve this answer|||||
  • 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 0: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 0: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 0:17
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.

|improve this answer|||||
  • 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
  • @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
  • 2
    @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 seagate.com/www-content/product-content/ssd-fam/1200-ssd/en-us/… – sawdust Aug 17 '17 at 23:13
  • @sawdust see my comment in David Schwartz's answer. – Tom Yan Aug 17 '17 at 23:38
  • 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 0:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.