This project has moved and is read-only. For the latest updates, please go here.

TRIM Not Working

Topics: Technical Issues
Feb 12 at 7:04 AM
Edited Feb 12 at 7:29 AM
In the veracrypt documentation I'm seeing it mentioned that VC doesn't stop the TRIM command - but after encrypting my system partition (SSD) I'm noticing TRIM no longer reports to be working via the "trimcheck" utility. However, instead of the normal "TRIM is WORKING" or "TRIM is NOT WORKING" - I'm getting "CONCLUSION: INDETERMINATE".

(I've tried ticking the "Enable extended disk control codes support" option - but no luck. Would that make any difference? I'm not 100% on what that's actually doing...)

Looking at the drive with a hex editor, I'm not seeing the zeros. However, I'd trimmed the drive shortly before encrypting it, and didn't do a wipe, with over 70% of the drive empty - so I'm assuming what I'm seeing is some result of veracrypt's driver?

Is there a proper way for me to tell if TRIM is actually working or not? I'd very much prefer it were.
Feb 12 at 7:38 AM
For data drives VeraCrypt creates virtual disk and emulates disk functions.
For system drive VeraCrypt does not create virtual disk. It works like ordinary disk filter. Probably VeraCrypt should not affect TRIM on system. My system is encrypted on SSD.
Feb 12 at 5:56 PM
Edited Feb 12 at 6:07 PM
kavsrf wrote:
For data drives VeraCrypt creates virtual disk and emulates disk functions.
For system drive VeraCrypt does not create virtual disk. It works like ordinary disk filter. Probably VeraCrypt should not affect TRIM on system. My system is encrypted on SSD.
Right right - so it's very possible what I'm seeing in-place of the zeroes I'm expecting is what VC is interpreting those zeroes to be after decryption (I don't suppose it bothers to differentiate between files and free space - since that would cause a host of other issues).

BUT, the behavior does appear to have changed at least somewhat.

Any idea if IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES is actually required for TRIM? I'm wondering if the extended disk control codes not being enabled are causing some issues with it.
Feb 12 at 7:52 PM
Probably you are right. System drive is filtered by VeraCrypt. So empty data inside system volume is decrypted also.

How do you check TRIM?

Do you have partition non-encrypted on the same SSD in addition to system? Try check trim on it.

I did not trace IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES. Probably this is for crash dumps and hibernate.
Feb 12 at 8:30 PM
kavsrf wrote:
Probably you are right. System drive is filtered by VeraCrypt. So empty data inside system volume is decrypted also.

How do you check TRIM?

Do you have partition non-encrypted on the same SSD in addition to system? Try check trim on it.

I did not trace IOCTL_STORAGE_MANAGE_DATA_SET_ATTRIBUTES. Probably this is for crash dumps and hibernate.
Unfortunately I don't have one unencrypted to test with at this point - though I wish I'd left a space now for testing. If I have enough time for a backup/decrypt/encrypt/test/restore next week I'll see what it looks like.

I'm checking trim via a utility called "trimcheck" - https://github.com/CyberShadow/trimcheck/releases
I also tried the hex editor method (pick a file on another drive, copy a unique string from the file, move it to your SSD, find the location, delete the file and observe the location 30 seconds later - it should be zeroed).

Interesting, that method specifically mentioned TRIM - but it doesn't seem to be making much difference either way. At least in my case, the extended control codes don't seem to do much of anything.