No DZAT support should result in "indeterminable" conclusion

[i3v]

I suspect, that the proposed method may not work, if SSD does not support DZAT (Deterministic Read Zero After Trim). This document provides some details, related to DZAT vs Deterministic Read After Trim (DRAT). Missing these two "features" does not actually mean missing TRIM.

Here's a post about an SSD that only supports DRAT.

Another example: my "Kingston SHPM2280P2H/480G" seem to have neither DRAT nor DZAT, at least hdsentinel shows that "Deterministic read after Trim" is not supported. Thus, trimcheck-0.7-win64.exe shows that TRIM is off. Still, my Windows 10 correctly detects that this drive is an SSD (disk optimizer tool suggests to TRIM, not to defragment). And hdd sentinel shows that TRIM is supported and functioning (even though I do not understand how it checks this).

Finally, here's one more story about a combination of the parameters.

[CyberShadow]

Can DZAT be detected on HDDs behind RAID?

The main use case for trimcheck is checking whether TRIM passthrough is working on the storage controller.

[CyberShadow]

Perhaps it would still be possible to detect DZAT by writing less than a page to a trimmed page... if the page actually has been trimmed, then the data on the remainder of the page should be lost.

[i3v]

Can DZAT be detected on HDDs behind RAID?

I'm not 100% sure, but it looks like this is possible. ( Moreover, I'm not an expert in this field, and I've got zero practical programming experience here. )

Here's a post, that provides some details about DRAT/DZAT, including a link to an official doc. So, they are talking about the ATA IDENTIFY command word169->bit0, word69->bit14 and word69->bit5.

Personally, I'm dealing with 2 PCs: For the PC I've already mentioned (self-assembled, with PCIe "Kingston SHPM2280P2H/480G", OC34L5TP firmware), Intel Solid-State Drive Toolbox version 3.3.5 on Windows 10 shows the following drive details:

1. word169->bit0 = 1 (supported)
2. word69->bit14 = 0 (deterministic read after trim = false)
3. word69->bit5 = 0 (not sure what this means, cause the table says "reserved". Probably, that's an imminent result of word69->bit14 = 0).

My experiments with trimcheck-0.7-win64.exe typically give “not kicked in yet” for weeks, then “INDETERMINATE” (I’ve seen “TRIM is working” once) . By the way, the rumors, that windows does not support PCIe SSDs do not apply here, cause “Kingston SHPM2280P2H” just emulates standard ACHI controller + disk.

Next, on another my PC (Dell 7910, "Micron M550 512GB SSD" with DL06 firmware, attached to "LSI SAS3 3008 Fury" RAID controller), same Intel SSD Toolbox, on Windows 7 is unable to obtain any drive details. Not sure why. But, hdsentinel still shows that "Deterministic read after Trim" is supported. I suspect that it reads the same info somehow. So, there might be some caveats, with reading this data through a RAID controller, but it looks like this is possible.

Perhaps it would still be possible to detect DZAT by writing less than a page to a trimmed page... if the page actually has been trimmed, then the data on the remainder of the page should be lost.

Hm... The “page” is a minimal “addressable volume” for the write operation, and “block” is a minimal addressable volume for erase operations. And each page within a block could only be written once after the whole block is erased. So, regardless of TRIM, the non-written part of the page should be zero, AFAIU. Moreover, other non-written pages within the same block should be zero too.

The problem is, AFAIU, only SSD controller knows "which LBAs is assigned to a specific page" == “the LBA to PBA translation table” == FTL.

So, I’m not sure I understood you correctly… Do you mean “it is possible to detect if-TRIM-is-functioning-OK for non-DZAT SSD by writing few pages, less than a complete block, to a trimmed block”?

I’d say this approach should work…. But the whole procedure would look significantly different from the current implementation… At least for me it looks like this:

1. For simplicity, let's assume that the size of advanced-format sector corresponds to SSDs physical page size and equals 4096 bytes. And that SSDs physical block size is 16 KB.
2. Create four files, 4096 bytes each, next to each other (might be tricky), on the SSD physical address level, so that they all would fit into a single SSD block (this page says that minimal block size is 256 KB).
3. Delete 2nd file (with a standard OS call)
4. Wait for OS to send the TRIM signal - AFAIU, under high load, OS may choose to wait a bit, before sending the TRIM command, cause this command might take a long while, especially if it’s “non-queued” type. Or force the OS to run the “disk optimization”.
5. Wait for SSD to actually execute the TRIM command, if it’s “queued” type. (should not take more than few seconds).
   • Assuming DZAT=1, the read command should give 0s immediately after the TRIM command was executed. Even if the garbage collector had not physically erased the block yet. Anyway, 0s mean that TRIM is working. And this probably means that the whole check should not take long for DZAT=1 SSDs.
   • Assuming DRAT=0 and SSD garbage collector is “background” type (ref1, ref2, ref3) the block would be physically erased after a while (here comes those typical recommendation to leave your PC running overnight). But it does not guarantee that by reading the LBA of the 2nd file we would read this specific PBA. The “INDETERMINATE” in the documentation means that is perfectly legit to send any random numbers as response to such a “read” request. Nevertheless, in practice, my experiments with trimcheck-0.7-win64.exe typically give “not kicked in yet” for weeks, and then “INDETERMINATE” or, rarely, "TRIM is working". It's a pure speculation, but it looks like it means they decided to keep the corresponding part of the FTL as is (why change it?) as long as this whole part of the FTL won’t get “refreshed” for some reason. And the "this page is invalidated" information is stored elsewhere.
   • Assuming DRAT=0 and SSD garbage collector is “foreground” type (I’m not actually sure, if “Marvell 88SS9293”, used in “Kingston SHPM2280P2H” is “background” of “foreground” type), we would probably see the same thing as in the previous case. The difference is that the block won’t be physically erased, until there would be a need to write some new data there. But this does not mean that TRIM is not working.
6. To avoid using this assumption, let’s change something in file1, file3 and file4, those next to the deleted file2. Let’s call the physical block, containing all these 4 files “PBA1000”, in accordance with the mentioned article. Since there’s no empty pages left in “PBA1000”, the updated data would be written to a new block, “PBA2000”.
   • If TRIM is not functioning, regardless of the SSD garbage collector type - SSD would think that the data on the 2nd page of PBA1000 block is still useful. So, even if GC would decide to erase almost-completely-stale” PBA1000 for some reason, the data from file2 must be copied to another PBA first. Moreover, the LBA of the “file2” must not change.
   • If TRIM is functioning, and SSD garbage collector is “background” type - the SSD should understand that the whole PBA1000 is invalid. The page, containing file2 won’t be copied to PBA2000 – which is the essence of the TRIM idea. The GC would erase PBA1000. Sometime, overnight. After that, reading LBA of file2 won’t give the same data, which was placed into file2. It still might be a non-zero, random data, though. (So, we have to make sure that no program would write anything to this LBA. I’m not sure how to achieve this… Boot from a USB-stick? Or just performing few millions of individual experiments?) Thus, assuming we’re dealing with a “greedy” background GC (trying to erase as much blocks as possible), we may assume, that we have an answer, even for DRAT=0 SSD.
   • If TRIM is functioning, and SSD garbage collector is “foreground” type – things get more difficult. Even if SSD understands that the whole PBA1000 is stale, it may keep PBA1000 as is, by the definition of the “foreground GC”. Personally, I’d say that a reasonable foreground GC algorithm should erase completely-stale blocks just like background GC, it should only behave different for partially-stale blocks, to reduce write-amplification. This provides a chance, that we would be able to see that TRIM works… Still, it could be a rather small chance. To improve this chance, the only approach I see is to write new random numbers to all other LBAs. May be even twice. If the LBA-of-file2 would still contain the same data after that – chances are that SSD treat this data as valuable, and that TRIM command was not received appropriately.

Few additional sidenotes:

• One of the most difficult questions is how to achieve “2” here. Due to SSD nature, even sequentially created files might be stored in completely different PBAs. There should be some trick, which would make this possible. Personally, the only approach I see is to completely fill the whole SSD with such files – this would almost guarantee, than most of them would be next to each other. May be even without a real file system, in a sector-by-sector manner.
• I suspect that some issues are possible, if LBAs are not aligned with SSDs blocks (ref1, ref2,ref3).
• AFAIU, today’s SSD controllers use a combination of foreground and background GC – they clean few gigs to provide maximum write speed if user would want to create some new files, but they never completely clean the whole surface, to reduce “write amplification”
• Some SSDs, like Kingston SHPM2280P2H/480G implement a hardware “data compression” (a hash-table-based data deduplication, AFAIU), to increase speed, and reduce the amount of data, being actually written. This means one need unique, uncompressible data for all these tests. (By the way, as an another speculation – it looks like this technology provides an additional motivation to use foreground-style GC, and only erase a small portion of the “stale” data – in this case the hash table is more useful, and “stale” data could become “normal” again.)
• All these experiments require a lot of FlushFileBuffers(), which may not actually work due if Turn off Windows write-cache buffer flushing on the device is enabled – looks like another thing to document down… Or maybe even to throw a warning, if it’s detected...
• SSD/RAID built-in RAM buffers might be quite large nowdays. Up to few GB. And I’m not absolutely sure they all do honor the “flush” commands appropriately. It looks like “power off/power on” cycle is the only 100% guarantee here. Not sure…
• This whole algorithm proposed here looks a bit bulky (and, after all, it might be incorrect – I’m not 100% sure about it). It doesn’t look like a small fix anyway. The nice small fix would be to warn user about DZAT=0 – warn that his TRIM might be working, even if he receives “not kicked in yet” (or ” INDETERMINATE”).

Sorry for such a long post :)

[CyberShadow]

Thank you for your very detailed analysis.

Unfortunately, this is much more involved than I can afford to work on right now. I've moved all my physical machines on Linux (where I use software RAID with BTRFS), and only run Windows in a VM, so no longer have any machines where I can test the program. Furthermore, as far as I know, all my SSDs do support DZAT.

The suggestion to detect DZAT through ATA commands is reasonable, however it would be a new endeavor for trimcheck, as it does not interface with drives directly, and only operates through Windows file system and volume I/O APIs.

For now, I pushed a small change adding a mention regarding DZAT to "not working" results.

You seem to have done a great deal of research on the subject. If you are interested in formulating it as a pull request, or even take over maintenance of the program, I would be glad to help where I can.

[i3v]

Thanks for your kind proposal! Unfortunately, currently I don't have enough free time either... Thanks for the modifications you've pushed - I believe that the most important thing here is to warn user, that things might be more difficult for non-DZAT SSDs.

[Squall-Leonhart]

just read through this, i have a mx500 1TB and 2TB and neither report DRAT as supported under ATA features

with no writes to either "TRIM" returns as indeterministic after 20 seconds.

these devices use the Silicon Motion SM2258 controller.