new: SSD TRIM check tool

[taltamir]

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

It is not better then nothing because it doesn't do anything except perform random tests which cannot possibly be used to detect trim status and then providing a random result based on those useless unrelated tests that has nothing to do with what it claims to detect.

It's like using dousing rods to detect cancer and saying "dousing rods are better then nothing even if it is impossible for them to actually detect what they are claimed to and the result they provide is random".

 

[Phynaz]

Nice analogy taltamir.

 

[CyberShadow]

Sorry for my absence. Even though I subscribed to this thread, for some reason the forum software didn't email me to notify of new posts, so I thought the thread had quieted down. I'll try to catch up now.

You mean it produces the result you expect, which doesn't mean it produces the correct result.

Actually, the tool reliably produces the correct result in all known cases.

Of course, it is up to your interpretation of what you consider the correct result. It seems that the entire disagreement is wrapped around semantics.

Let us review what has already been discussed in this thread:

1. It is impossible for a tool such as TrimCheck, to determine, with 100% certainty, whether TRIM is working (for any reasonable definition of the word).

I agree with this point.

2. TrimCheck's purpose is to attempt to automate the hex editor method described in this AnandTech article.

Whether you consider the described method reliable or not, this point is not subjective.

3. A tool that produces the correct result in 95% of cases is still useful, and "better than nothing" (assuming its users are aware of possible faults).

I think disagreeing with this point is up to personal principles, and arguing about it is not constructive.

4. Certain patterns of disk activities (file creation and deletion, then reading disk data from certain logical sectors) allow observing the TRIM effect, with some degree of reliability.

This point is important: TRIM activity is not completely random. In most cases, it in predictable, and the reliability can be quantified.

5. Through experimentation and incremental improvement, it is possible to develop a set of disk activity patterns that have incrementally higher reliability in observing the effects of TRIM, for the tested system configurations.

Again, I don't consider this subjective.

6. The tool's description may have created a false impression in this thread, in that it either works in a way that it actually doesn't, or that it attempts to accomplish something else than what it actually does.

For example, at the beginning of this post I've used the "correct result" term - with the underlying meaning that it performs a disk access pattern, and displays a result: a few hex bytes, and a conclusion.

Please take special note of the conclusion's wording: it will read either "TRIM appears to be NOT WORKING" or "TRIM appears to be WORKING". The key point here is "appears" - the wording makes no intention to hint at certainty. This has always been so from the first program version.

To stress it out: I have never stated that the conclusion displayed by the program is a factual guaranteed representation whether TRIM is working or not. The conclusion is correct in the meaning that the program works exactly as designed: to follow an algorithm, which attempts to make a best effort of determining whether TRIM is working.

Considering the above, I'm not sure what's your beef with TrimCheck. If you think the documentation should be improved to better describe its workings and purpose, I'd gladly accept some constructive tips.

As for the rest of your post:

Even if it did produce the "correct" result, correlation <> causation.

Correct. See above. In most cases, the result is a causation of the disk access patterns issued, however this is not guaranteed. False negatives are a possibility, and to a lesser extent, false positives as well (for example, if some kind of a resident disk wiper program is running).

Again, as has been stated by quite a few others here: Without access to the low level information about the drive - which you cannot get from Windows - you have no way of telling if TRIM is working or not.

Correct - if you want 100% certainty.

Sorry, but your tool doesn't work because it CAN'T work.

I conjecture that your statement is based on a misconception of the tool's purpose. Hopefully that matter is clarified now.

I know it's difficult to be shown to be incorrect when you have put a lot of effort into something. It's probably best to treat it as a learning experience.

Thank you for the sympathy, though TrimCheck is just a tool I've done in a few hours - I don't intend to get famous off it or spend a lot of time on it in the future. In fact, I've probably learned more from writing a constructive answer to your post

It is not better then nothing

I will have to disagree with you here, based on anecdotal evidence. A few people have gotten a negative result with TrimCheck, and upon investigating the cause, have discovered that there was actually a reason (incompatible software / incorrect drivers) that resulted in TRIM actually not working (said software had a known issue with TRIM, or the drivers did not support TRIM). Upon resolving the issue, TrimCheck began returning positive results. I consider this a win for the program, so I personally don't consider it worse than nothing

 

[TimeKilla]

Hi CyberShadow,

I just registered here to say thank you very much for you're tool it seems to work fine! Keep doing what you're doing buddy not sure why you're getting such a hard-time over here for trying to help people out for free!

I would have made a small donation to you very small as very small program lol

If you have a blog or anything to follow projects you're working on send me a PM.

Peace from Scotland :whiste:

 

[Coldblackice]

Curious, indeed! Thanks for your work!

 

[tweakboy]

I would prefer Crystal Disk Info ........... same thing but more info. gl

 

[glugglug]

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

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).

The actual SATA TRIM command spec states that read operations on TRIMed clusters are to return 00.
So if a drive returns FF, that is technically a buggy firmware.

Something else I'd like to see added:
Check for what I would call "orphaned data" when you TRIM smaller than the drive page size.

For example:
Lets say your drive has 16K pages, but you formatted with 4KB.
A single 16K page will contain 4 4KB clusters. If you TRIM only the middle two clusters, the drive can't really do the TRIM, because maybe the other 2 are still in use by some file. Even if you TRIM all 4, but do them one at a time (with some operations on other data in-between), I doubt the controller will maintain enough state to know the entire page can now be TRIMed. It can probably only be reclaimed if all 4 are TRIMed in a single operation.

 

[glugglug]

Concluding, there is no theoretical limitation on RAID5 and TRIM support. If an implementation doesn't support it, that is a limitation of that specific RAID subsystem and/or operating system, not the fault of RAID scheme itself.

Yes, actually there sort of is. It isn't actually guaranteed that the drive can TRIM the range of clusters you tell it. (For example, the range can include a partial page, and the drive can't assume the other data in the page isn't still in use). So after the TRIM, you don't know what to put in the parity stripe. The only solution then is to zero any erased data before TRIMing it, so that deterministic parity stripe data can be calculated in case the TRIM doesn't actually get followed through. So you have extra writes the size of the data you are deleting plus the parity, which kind of defeats the purpose of TRIM in the first place. Unless you happen to have a smart SSD controller which treats zeroing a page the same as TRIMing it. I think that is effectively the case for Sandforce because of the compression.

 

[Fred B]

Thank you for the sympathy, though TrimCheck is just a tool I've done in a few hours - I don't intend to get famous off it or spend a lot of time on it in the future. In fact, I've probably learned more from writing a constructive answer to your post

i use xp and dont have trim automatic but with the intel optimizer ,when trim works the acces times go down.

Why does the program write to index.dat files
http://i.imgur.com/KgydsPQ.png

 

[Schmide]

Why does the program write to index.dat files
http://i.imgur.com/KgydsPQ.png

Being an outside party. I can only imagine because it needs persistence between runs about location of trimmed memory. It is thusly saving their locations in that file.

 

[CyberShadow]

The actual SATA TRIM command spec states that read operations on TRIMed clusters are to return 00.
So if a drive returns FF, that is technically a buggy firmware.

If I recall correctly, FF was returned by an old firmware version, so that lines up.

Something else I'd like to see added:
Check for what I would call "orphaned data" when you TRIM smaller than the drive page size.

Interesting idea. It'll need some thought regarding the implementation (arranging the data in clusters, and triggering garbage collection or getting the user to do it).

Why does the program write to index.dat files
http://i.imgur.com/KgydsPQ.png

Probably because trimcheck.exe needs shell32.dll (needed by the language runtime, used for command-line parsing), which needs wininet.dll, which touches index.dat on initialization.

 

[Fred B]

Being an outside party. I can only imagine because it needs persistence between runs about location of trimmed memory. It is thusly saving their locations in that file.

Oke

THe program works fine with xp with raid also , moved to the Z77 for ssd raid trim support .It makes living a lot easyer ,no op ,no secure erase to refresh the the array.

 

[Dufus]

The actual SATA TRIM command spec states that read operations on TRIMed clusters are to return 00.
So if a drive returns FF, that is technically a buggy firmware..

That is only if zero return after trim is supported. Otherwise it can return what ever it likes. However IMO returning 0's is likely more compatible with software. For instance having the MBR all FF might confuse some BIOS.

Trim works fine for 4k with 8k page, most of my trim testing uses just 4k. Many people confuse trim with erasure. Trim only unmaps, its up to the SSD firmware to erase when it deems suitable. With trim the 4k is unmapped and a new mapping made not to the physical flash, but for instance to a special buffer allocation until that 4k is written to. The SSD has to keep track of all logical sectors.

 

[taltamir]

The actual SATA TRIM command spec states that read operations on TRIMed clusters are to return 00.
So if a drive returns FF, that is technically a buggy firmware.

Actually the whole point of the DRAT and DZAT amendments to trim standards is to rectify the oversight of NOT initially requiring TRIM to be determinate.
http://en.wikipedia.org/wiki/Trim_(computing)#Hardware_support

 

[glugglug]

Actually the whole point of the DRAT and DZAT amendments to trim standards is to rectify the oversight of NOT initially requiring TRIM to be determinate.
http://en.wikipedia.org/wiki/Trim_(computing)#Hardware_support

Interesting.

Also, this app alerted me that I had not been using TRIM on my old box the past 2 years. I had been using Intel Matrix Storage Manager with an Intel X-25 G1 (since the G1 didn't support TRIM, it didn't matter that Matrix Storage Manager didnt' support it either). I upgraded to an Agility 2 in 2011, and remembered reading that Intel had finally added TRIM support to their drivers in 2010, so I figured I should be good with the latest Matrix Storage Manager. Apparently the TRIM was only added to the Intel RST drivers, not the MSM drivers they replaced, and it won't let me install RST with an old Bloomfield board, so now I am using the default MS AHCI drivers on there.