Linux 5.19 Allows Using TRIM To Zero-Out Sectors On Supported eMMC

[phoronix]

Phoronix: Linux 5.19 Allows Using TRIM To Zero-Out Sectors On Supported eMMC

Last week the (e)MMC storage new feature code landed into the Linux 5.19 merge window...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.19-MMC

[Developer12]

One would hope that the kernel will actually check a couple of these sectors to verify that they're actually being zeroed.

[milkylainen]

One would hope that the kernel will actually check a couple of these sectors to verify that they're actually being zeroed.

Since an eMMC has a FTL there is little to no value in the meaning of a LBA (in the physical sense) or a TRIMed LBA data contents.
A _zeroed_ sector is an actual data write and is no different than other data writes.
Also. A zeroed sector is the worst data a NAND media sector can have..
In the sense that it _will_ require an erase cycle to change any bit of it.

Ie. Zero != TRIM.
The choice of words in headline (or the original commit/annoucement) is rather bad, from a technical storage perspective.

[Anux]

Also. A zeroed sector is the worst data a NAND media sector can have..
In the sense that it _will_ require an erase cycle to change any bit of it.

I'm more familiar with SSDs and thought eMMC would behave the same. If you Trim a sector on an SSD the sector gets mapped out of your reach and becomes aviable for the next write. Its not zeroed out but if you access that sector again you will get zeros or random data (depending on if and how the SSD applys encryption in hardware).

Is eMMC fundamentally different to SSDs?

[milkylainen]

Is eMMC fundamentally different to SSDs?

I think you missunderstood me.
I said Zero != TRIM.
Which is what you are saying too? And yes, they're pretty much the same.

The wording in the post confuses zeroing with TRIM.

[Anux]

The wording in the post confuses zeroing with TRIM.

Ah ok, real zeroing is really hard to do from the software side. If I understand the article correct it is for devices that report zeros for unwritten or trimmed sectors but that doesn't mean they got overwritten with zeros in hardware.
hdparm will give

deterministic read zeros after trim

for such devices.

[milkylainen]

Ah ok, real zeroing is really hard to do from the software side. If I understand the article correct it is for devices that report zeros for unwritten or trimmed sectors but that doesn't mean they got overwritten with zeros in hardware.
hdparm will give

deterministic read zeros after trim

for such devices.

Yes. Probably reasonable to return zeros from a software perspective.
I would stick to saying "TRIM" for trimming and "Zeroing" for actual writing zeros to a LBA.

[Anux]

I did a little more reading about that topic and turns out that REQ_OP_WRITE_ZEROES actually is an extension to the trim command that lets the hardware itself write zeros instead of only triming. It must be something different from "read zeros after trim".
The article is much more accurate than we thought.

The difference between the two would obviously be that classic trim of a whole device is much faster and write zeros would be as slow as dd /dev/zero /dev/ssd (or slightly faster because we skip the I/O-interface and CPU).

[binarybanana]

Note that at least on SD cards trim is already supported, at least if the controller also supports it. Some do, some don't.

[Developer12]

Since an eMMC has a FTL there is little to no value in the meaning of a LBA (in the physical sense) or a TRIMed LBA data contents.
A _zeroed_ sector is an actual data write and is no different than other data writes.
Also. A zeroed sector is the worst data a NAND media sector can have..
In the sense that it _will_ require an erase cycle to change any bit of it.

Ie. Zero != TRIM.
The choice of words in headline (or the original commit/annoucement) is rather bad, from a technical storage perspective.

I'm not talking at all about the substrate that makes up the drive. I'm talking about bugs.

Every little-used feature is buggy until proven otherwise (and in the process it's really only proven to be buggy). That is the ironclad rule of relying on closed-source firmware.