new: SSD TRIM check tool

[Fernando 1]

Some days ago I found >this< thread at The SSD Review Forum, where a brandnew "SSD TRIM Check Tool" was discussed. The developer of the tool is a Russian named Vladimir Panteleev (nick name: CyberShadow). His Blog with the details can be joined >here<.
As you can read within the linked Forum thread, I have tested the new tool intensively and found, that last test versions are giving accurate results within a minimum of time.
This is what the users have to do:

1. Download the latest tool version from >here<.
2. Copy the EXE file into the root of C:
3. Right click onto the EXE file and run the tool as Administrator.
4. Hit the "Enter" button.
5. Rerun the tool as Admin ca. 15 seconds later.
6. If you should get the message "TRIM appears to be NOT WORKING", rerun the tool in intervals of round about 15 seconds.
7. At least you should get the message "TRIM appears to be WORKING" (provided it really is active within your single or RAIDed SSD).

Any feedback would be much appreciated.

 

[Vectronic]

Well, it didn't try destroying my SSD or deleting Windows files... that's a bonus.

The only feedback I have is... get rid of the "15 second" thing, should be possible for it to "resume" itself.

 

[Hallo32]

removed

 

[Phynaz]

When executed for the first time it will write on specific locations on the SSD. It will then delete the written data and exit. When you run it a second time a minute later, it will try to read the exact same locations. When TRIM works you'll get zeroes on the sectors it wrote, plus a notification that TRIM works.

I call BS, as there's no way a program can write to "specific locations". The controller on the SSD remaps any writes to the SSD.

 

[Fernando 1]

I call BS

Whom do you want to call? Who is "BS"?

 

[GarfieldtheCat]

Whom do you want to call? Who is "BS"?

It's slang for "not believing it"....he is saying "I call bullshit", claiming that it is false.

 

[kbp]

I call BS, as there's no way a program can write to "specific locations". The controller on the SSD remaps any writes to the SSD.

It does write to a location and then rechecks that "specific" location for the data which is no longer there. I've compared it with a hex editor and it indeed works, at least on my computer.

 

[imagoon]

It does write to a location and then rechecks that "specific" location for the data which is no longer there. I've compared it with a hex editor and it indeed works, at least on my computer.

Any current SSD would have remapped the sector(s) it connected to. You would need to use manufacturer specific commands to review the true SSD cells.

IE if you request a TRIM of a random sector, then reread it, there is no way to verify that a different set of cells were not remapped in.

In addition, TRIM is simply a delete notification so the drive may have working TRIM and simply 'hasn't bothered' to clear the sector in question yet. TRIM just gives a "to do" list to garbage collection and GC can run when ever it really feels like it.

Long story short, without knowing how it is testing TRIM, I wouldn't assume the tool has any clue really.

 

[Elixer]

Any current SSD would have remapped the sector(s) it connected to. You would need to use manufacturer specific commands to review the true SSD cells.

IE if you request a TRIM of a random sector, then reread it, there is no way to verify that a different set of cells were not remapped in.

In addition, TRIM is simply a delete notification so the drive may have working TRIM and simply 'hasn't bothered' to clear the sector in question yet. TRIM just gives a "to do" list to garbage collection and GC can run when ever it really feels like it.

Long story short, without knowing how it is testing TRIM, I wouldn't assume the tool has any clue really.

+1

From looking at the source, here, https://github.com/CyberShadow/trimcheck he says, all it does is "uses sector calculations to avoid searching the entire drive for the sought pattern. It also pads the sought data with 32MB blocks of dummy data, to give some room to processes which may otherwise overwrite the tested deteled disk area"

 

[CyberShadow]

Yes, it's just heuristics. It attempts to be at least as accurate as the popular method involving a hex editor (it's not quite there yet, but I'm working on it).

 

[Phynaz]

It does write to a location and then rechecks that "specific" location for the data which is no longer there. I've compared it with a hex editor and it indeed works, at least on my computer.

So what you confirmed is both this tool and a hex editor don't work.

See my initial post. You cannot tell an SSD to write to specific area (cells), period.

When reading from an SSD you have no idea where (which cells) you are reading from. Period.

 

[CyberShadow]

Phynaz, I'm not really sure what your point is as I don't think anyone in this discussion made the allusion that the tool attempts to access specific physical addresses (or "cells") on the SSD. All operations are done using Logical Cluster Numbers, which are an OS abstraction.

 

[JellyRoll]

Yes, but the tool doesn't work is the end result.

 

[Phynaz]

Phynaz, I'm not really sure what your point is as I don't think anyone in this discussion made the allusion that the tool attempts to access specific physical addresses (or "cells") on the SSD. All operations are done using Logical Cluster Numbers, which are an OS abstraction.

Since you're new here I'm going to assume you don't know how SSD's actually work.

Here's a good article to begin with http://arstechnica.com/information-...revolution-how-solid-state-disks-really-work/

Then you may be able to figure out why there isn't a way to tell if trim is actually working from the user perspective.

 

[murphyc]

I think this is problematic because sata-io doesn't specify the time to garbage collection or what data should be returned before garbage collect has occurred. For purposes of data recovery, it's reasonable for garbage collection to take quite a bit longer than 1 minute, or even a day. Every SSD firmware is different in how it balances static and dynamic wear leveling.

The application could write a test file, and then obtain the LBAs allocated for that file by the file system. Then the file could be deleted, which should cause the file system to issue the SATA TRIM command to the drive. That flags the equivalent physical pages on the SSD to be marked for garbage collection. However, erasure only actually occurs when all pages in an erase block are so marked, and on a timing of the firmwares choosing. If even one page in a block isn't marked for erasure, it could be minutes, hours or days before the firmware decides to statically move that data to some other physical page so that erase block can be erased.

I don't understand what question the check tool is trying to answer, that a tool like manufacturer specs, or hdparm -I, doesn't return.

 

[Fernando 1]

I don't understand what question the check tool is trying to answer.

The TRIM Check tool is trying to answer the question: Does the TRIM command pass through the Intel SATA RAID Controller into an SSD RAID0 array or not?
This question arised especially by the findings of Dufus, which he had layed down >here<. Many users with an Intel 5- or 6-Series chipset RAID0 system want to know, if they got the "TRIM in RAID" feature by flashing the modded Intel RAID ROM or not.

 

[murphyc]

Does the TRIM command pass through the Intel SATA RAID Controller into an SSD RAID0 array or not?

I think testing in the described manner will produce false negatives. Without knowing the specific behavior of the SSD being testing, you can't know for sure that non-zero information returned for the test file LBA's means TRIM failed. It may just have slow garbage collection (some might call this efficient rather than slow).

Many users with an Intel 5- or 6-Series chipset RAID0 system want to know, if they got the "TRIM in RAID" feature by flashing the modded Intel RAID ROM or not.

If the firmware modification is designed to enable TRIM passthrough where it previously wasn't enabled, then why would it fail?

Either you know all the components support TRIM down to and including the drive; or you do what anandtech do when reviewing an SSD which is a performance benchmark based test for TRIM.

 

[Engineer]

If the firmware modification is designed to enable TRIM passthrough where it previously wasn't enabled, then why would it fail?

Because it's being modded by "enthusiasts" instead of by Intel and the motherboard makers. It needs to be tested and debugged to make sure that it works across the chipset types as well as the various motherboard BIOS combinations out there.

 

[murphyc]

It needs to be tested and debugged to make sure that it works across the chipset types as well as the various motherboard BIOS combinations out there.

I understand that, but the test seems flawed. If the test app is merely asking for LBAs that should have previously been issued TRIM, just because non-zero data is returned doesn't mean TRIM wasn't issued. It could also mean garbage collection hasn't yet occurred.

 

[CyberShadow]

Yes, but the tool doesn't work is the end result.

According to my tests, the tool produces the correct result in the great majority of cases.

Since you're new here I'm going to assume you don't know how SSD's actually work.

I am the creator of TrimCheck. I would appreciate less assumptions of ignorance about newcomers.

The application could write a test file, and then obtain the LBAs allocated for that file by the file system. Then the file could be deleted, which should cause the file system to issue the SATA TRIM command to the drive. That flags the equivalent physical pages on the SSD to be marked for garbage collection. However, erasure only actually occurs when all pages in an erase block are so marked, and on a timing of the firmwares choosing. If even one page in a block isn't marked for erasure, it could be minutes, hours or days before the firmware decides to statically move that data to some other physical page so that erase block can be erased.

I don't understand what question the check tool is trying to answer, that a tool like manufacturer specs, or hdparm -I, doesn't return.

It provides an easy way to test if the TRIM actually occurred, for the circumstances that the tool tests and the manner the user uses it (i.e. how long the user waited for TRIM to occur). Tests show that using the tool in an appropriate manner (as described by its textual output) produces the correct result on whether TRIM is enabled and working in the great majority of cases.

I think testing in the described manner will produce false negatives.

As I mentioned above, it is a heuristic, and cannot guarantee to provide an answer with 100% certainty. Through continued testing and improvement, I believe we can achieve a testing algorithm which produces a very low percent of false negatives. Version 0.4, released yesterday, already improves in this regard.

If the test app is merely asking for LBAs that should have previously been issued TRIM, just because non-zero data is returned doesn't mean TRIM wasn't issued. It could also mean garbage collection hasn't yet occurred.

The tool does not test whether TRIM was issued. It tests whether garbage collection has occured.

 

[max347]

CMD
->
fsutil behavior query DisableDeleteNotify

no??

 

[CyberShadow]

DisableDeleteNotify checks if TRIM hasn't been disabled on your system. It does not provide any information on whether the system is actually sending TRIM commands to any particular drive, or whether the commands are actually acted upon.

 

[JellyRoll]

Either you know all the components support TRIM down to and including the drive; or you do what anandtech do when reviewing an SSD which is a performance benchmark based test for TRIM.

Even Anand gets it wrong with this testing, and terribly so. Anandtech did not mention the SandForce TRIM bug that was wide knowledge for six months on many sites. Then they mention it like it was a new discovery.
Anands test suite tests without the benefit of TRIM, since they test with no filesystem. Hence, it is somewhat unrealistic as it is.

 

[imagoon]

Honestly, the only way to really know it plug in an SATA protocol analyzer and watch for the TRIM commands.

However I can follow the logic here. If you write a pattern file then execute an OS erase and read that set of allocated sectors back and the disk returns all zeros or FF it indicates that something responded to that delete (TRIM) command. What responded is a bit harder to clarify. And a "failure" to me doesn't indicate that something like TRIM isn't there either esp in lazy garbage collection or the off chance you didn't manage to hit a full page.

Since the OS level sectors don't directly map to the SSD pages, and most SSD's do a copy on write so a single sector may still return values. There is no definition on what should be returned what a TRIM'd sector is read. It could return 00, FF, the original contents or the Bill of Rights in Unicode format if the firmware wanted it to.

 

[CyberShadow]

Since the OS level sectors don't directly map to the SSD pages, and most SSD's do a copy on write so a single sector may still return values.

The program generates a random block of data each run, so COW should have no role here.

There is no definition on what should be returned what a TRIM'd sector is read. It could return 00, FF, the original contents or the Bill of Rights in Unicode format if the firmware wanted it to.

The program currently recognizes 00 and FF as unallocated. I can add more patterns if anyone reports them. Regardless, the program prints the first 16 bytes of whatever it reads.

I agree with everything else in your post. I hope you'll agree that this tool is still much better than nothing (or having to run a performance benchmark).