Say if I write zero to a certain range of LBAs of a drive, then I TRIM those logical blocks (say, with blkdiscard or even hdparm). Given the drive has the Read Zero After TRIM behavior, is there a way for someone to tell whether the the logical blocks were TRIM'd or not?
(One way I could think of, which might work, could be a timed read to detect a faster response on trimmed data block than on a non-trimmed data block with all zeros, but this question is more about an API to just ask the disk.)
First, trim is not used for zeroing blocks. Trim is used to tell an SSD that a block is no longer needed and its contents can be discarded. The intent of trim is to actually help an SSD do write leveling by telling it that it can freely rewrite a block without first preserving its contents. As such, it doesn't necessarily make sense to take an extra step to zero the block first.
The SSD trim standard states that reading a trimmed block will produce undefined results, rather than a zero block, although some versions of the standard do include a "read zero after trim" version of trim. Since reading a trimmed block has undefined behavior, even ignoring cache issues, it is unlikely you will be able to tell if a block is trimmed by timing a read of it. Writing to a trimmed block might not have a timing difference either, as write leveling might cause a different physical block to be written anyway.
Since trim is intended to discard blocks, a filesystem would not use trim on a block in a file -- but only on a block freed from a file. So to ask if there is a way to tell if a block in a file has been trimmed makes no sense, because a filesystem would not do this to a file. If you do have a filesystem with trimmed blocks in files, the filesystem is likely corrupt. Even if you do have such a corrupt filesystem, the trim standard does not include any way to query if a block is trimmed, or even how many blocks on the SSD are trimmed. A better question would be to ask if there is a way to determine if a block in a file is corrupt. Some filesystems (e.g., zfs, others) do have this ability, but it may not be directly accessible outside of filesystem internals. In a RAID, on reading a corrupt block, the raid might log this event, but will also reconstruct the block and likely rewrite a good block in its place. If that fails, presuming the RAID doesn't just go offline, it might return an I/O error.
However if your filesystem is actually an image of a filesystem that is actually a file in another filesystem, fstrim can tell the operating system to release free blocks, which causes the underlying filesystem to actually create holes in the filesystem image file. Unlike trim on SSDs, the behavior of holes in files is very well defined, and will always return zeros. There are also (somewhat unportable) system calls that will allow a program to ask the filesystem where the holes in a file are.
I think you should ask the question in a better way, by not involving file or filesystem at all, since that seems to be your actual intest:
Say if I write zero to a certain range of LBAs of a drive, then I TRIM those logical blocks (say, with
blkdiscardor evenhdparm). Given the drive has the Read Zero After TRIM behavior, is there a way for someone to tell whether the the logical blocks were TRIM'd or not?
And the answer (from me) is, unless the vendor provides some vendor-specific way to check the mapping of the logical blocks to the actual storage, or you manage to hack the controller by some means to do the equivalent, no, there's no standard way in common protocols / command sets for someone to tell reliably.
dd. Speaking of that, some SSD controller were known to "optimize" normal zero writing, IIRC...
For NVME disks, there's a thing called DULBE, or Deallocated or Unwritten Logical Block Error. Here's a quote from chapter 3.2.3.2.1 Deallocated or Unwritten Logical Blocks in NVM Express® NVM Command Set Specification revision 1.0c October 3rd, 2022.
Using the Error Recovery feature (refer to section 4.1.3.2), host software may select the behavior of the controller when reading deallocated or unwritten blocks. The controller shall abort Copy, Read, Verify, or Compare commands that include deallocated or unwritten blocks with a status of Deallocated or Unwritten Logical Block if that error has been enabled using the DULBE bit in the Error Recovery feature.
For certain NVME disk models that support this feature, it seems you can utilize it to retrieve whether one block is trimmed/unwritten or not.
But I don't know any model by which this feature is supported, at least not by Samsung SSD 980 PRO 1TB or INTEL P4510 1TB:
# nvme id-ns /dev/nvme0n1 -H | grep "Deallocated or Unwritten Logical Block error"
[2:2] : 0 Deallocated or Unwritten Logical Block error Not Supported
I have asked myself the same thing. I had this hypothesis that since zeros that are result of TRIM, which are merely let's say "placeholders", are fundamentally different than sectors actually read the difference may be measurable.
You can observe a difference in read speed between say a volume of 100 GB that trimmed vs. one that is zero filled. The trimmed volume's read speed exceeds that of the zero filled volume. I don't have a benchmark at hand to demonstrate this, but I have seen plenty that do: a trimmed drive returns blocks of zeros on read but is dramatically faster than reading actual zeros that were written to the SSD.
Since reading from NAND requires 'increased power' to pump the NAND to required levels, and that this is not required to get 'trimmed LBA space' as the controller simply returns placeholder sectors this may be measurable too.
I have run some tests to confirm this and sort of as proof of concept, and those seem to support the idea, I need to repeat more refined tests some day. However I was able to measure a difference in power consumption when reading trimmed drives vs. zero filled drives although the difference was marginal:
Note that modern SSDs may apply compression at the firmware level and in that case all bets are off again!
