TRIM Support Enabler

[Caesar_091]

Just backup, patch, reboot and it works.

OWC Mercury Extreme Pro SSD:

Capacity: 115.03 GB (115,033,153,536 bytes)
Model: OWC Mercury Extreme Pro SSD
Revision: 360A13F0
Serial Number: MXE11511E11C1235
Native Command Queuing: Yes
Queue Depth: 32
Removable Media: No
Detachable Drive: No
BSD Name: disk0
Medium Type: Solid State
TRIM Support: Yes

What Mac model are you using?

TIA

 

[bbogey]

Better way to trim the unused blocks is to use fsck, at least with 2011 models. It seems fsck version needs to be the version what is shipped with 2011 models.
Boot in Single User mode (command + s)
When in console type

/sbin/fsck_hfs -ffy /dev/rdisk0s2

type exit to continue booting to OS X.



Please also see the thread here:

http://forum.hardmac.com/index.php?s=&showtopic=10047&view=findpost&p=18111

 

[Riot Nrrrd]

Better way to trim the unused blocks is to use fsck, at least with 2011 models. It seems fsck version needs to be the version what is shipped with 2011 models.
Boot in Single User mode (command + s)
When in console type

/sbin/fsck_hfs -fy /dev/rdisk0s2

type exit to continue booting to OS X.

View attachment 279598

Please also see the thread here:

http://forum.hardmac.com/index.php?s=&showtopic=10047&view=findpost&p=18111

Interesting ... the fsck_hfs in "normal" 10.6.7 is

[5:03] nightowl:/ % what `which fsck_hfs` | sort -r | uniq
/sbin/fsck_hfs
	 diskdev_cmds-491.3.3~1 02/21/11 17:48:52 PST

Note the version being older than that on the 2011 MacBook Pro version of 10.6.7 (491.3.3 vs. 491.6).

No TRIM support in 491.3.3:

[5:04] nightowl:/ % strings - `which fsck_hfs` | grep -i Trim
[5:04] nightowl:/ %

 

[Riot Nrrrd]

An interesting reply from that Hardmac thread:

"Not here (MBP 2010, Apple SSD 10.6.7 patched with the TRIM enabled kext from the MBP 2011); my /sbin/fsck is a different version though: are you running fsck from a MBP 2011 installation?"

One of the first things I thought about when I started reading this "TRIM Support Enabler" thread was, "OK, fine, so someone patched some stuff to recognize non-Apple SSDs - but it takes two to tango, you need to have TRIM support in the driver(s) as well, presumably". Maybe this "TRIM enabled kext from the MBP 2011" is just what I was thinking about.

What say you, Cindori?

 

[Cindori]

An interesting reply from that Hardmac thread:

"Not here (MBP 2010, Apple SSD 10.6.7 patched with the TRIM enabled kext from the MBP 2011); my /sbin/fsck is a different version though: are you running fsck from a MBP 2011 installation?"

One of the first things I thought about when I started reading this "TRIM Support Enabler" thread was, "OK, fine, so someone patched some stuff to recognize non-Apple SSDs - but it takes two to tango, you need to have TRIM support in the driver(s) as well, presumably". Maybe this "TRIM enabled kext from the MBP 2011" is just what I was thinking about.

What say you, Cindori?

the trim kext from MBP 2011 build enables trim for Apple SSD

the kext that this patch installs is a hacked version of that kext, that enables trim for any ssd

 

[RS2]

Looks like diskdev_cmds-491.6 have a trim unused blocks command that will be called when doing a verify or repair disk in Disk Utility with a SSD. But diskdev_cmds-491.6 is not available yet at the open source website so it's hard to check. Anyone with a MBP 2011 and an Apple SSD that can run verify disk in Disk Utility and see if you get the "Trimming unused blocks" in the log?

http://www.opensource.apple.com/source/diskdev_cmds/

 

[Lava Lamp Freak]

What type of SSD do you have? I ran this on an Intel X25 G2 and a 2010 MBA and am not seeing any negative trade-offs with the same applications you mention (except I don't play flash games so can't compare).

I ran the patch, erased disk free space and ran the patch again.

I have a 120GB OWC Mercury Pro that is one week old.

 

[Weaselboy]

Better way to trim the unused blocks is to use fsck, at least with 2011 models. It seems fsck version needs to be the version what is shipped with 2011 models.
Boot in Single User mode (command + s)
When in console type

/sbin/fsck_hfs -ffy /dev/rdisk0s2

type exit to continue booting to OS X.

Please also see the thread here:

http://forum.hardmac.com/index.php?s=&showtopic=10047&view=findpost&p=18111

I just tried this on my 2011 13" MBP with 10.6.7 and the TRIM patch and it works. Just went to single user mode and type "fsck -ffy" and it ran fsck and showed the "Trimming unused blocks" entry at the end of the scan.

 

[RS2]

I just tried this on my 2011 13" MBP with 10.6.7 and the TRIM patch and it works. Just went to single user mode and type "fsck -ffy" and it ran fsck and showed the "Trimming unused blocks" entry at the end of the scan.

Do you see the same "Trimming unused blocks" text in the history log if you run verify or repair disk in Disk Utility in normal mode?

 

[Weaselboy]

Do you see the same "Trimming unused blocks" text in the history log if you run verify or repair disk in Disk Utility in normal mode?

I did a verify and nothing about TRIM in the DU log. Can't repair in DU as it is my boot partition and only drive.

 

[RS2]

I did a verify and nothing about TRIM in the DU log. Can't repair in DU as it is my boot partition and only drive.

And if you run fsck_hfs test-only check from terminal in normal mode?

sudo fsck_hfs -l /dev/disk0s2

 

[Weaselboy]

And if you run fsck_hfs test-only check from terminal in normal mode?

sudo fsck_hfs -l /dev/disk0s2

fsck runs but no mention TRIM using that method.

 

[RS2]

fsck runs but no mention TRIM using that method.

That's OK since it's the same as performing a live verification on a boot partition via Disk Utility so you should get the same result.

But I'm curious how to run the trim unused blocks command via fsck_hfs in diskdev_cmds-491.6 without booting in single user mode?

If you can't trim unused blocks via verify disk I guess you have to do a repair disk which you can't do on a boot partition.

What about if you starting up in safe mode and check the fsck_hfs.log in both ~/Library/Logs and /private/var/log via the console?

Can you see the "Trimming unused blocks" text in any of these logs?

Maybe you can trick fsck_hfs to check and repair a clean file system via the -f option but not doing any repair via the -n option?

sudo fsck_hfs -n -f /dev/disk0s2

 

[Weaselboy]

But I'm curious how to run the trim unused blocks command via fsck_hfs in diskdev_cmds-491.6 without booting in single user mode?

If you can't trim unused blocks via verify disk I guess you have to do a repair disk which you can't do on a boot partition.

I agree. I don't think you can get to this TRIM command with going into single user mode.

 

[RS2]

I agree. I don't think you can get to this TRIM command with going into single user mode.

But what about starting up in safe mode since fsck_hfs will run then? Or using a 2011 MBP install DVD and run repair disk on the SSD with Disk Utility?

 

[Weaselboy]

But what about starting up in safe mode since fsck_hfs will run then? Or using a 2011 MBP install DVD and run repair disk on the SSD with Disk Utility?

I would think it will not work in Safe mode as the disk is still mounted. I suspect it would work form the install DVD though, but I am too lazy to dig it out of the closet/box.

 

[RS2]

I would think it will not work in Safe mode as the disk is still mounted. I suspect it would work form the install DVD though, but I am too lazy to dig it out of the closet/box.

In Safe Mode Mac OS X automatically verifies and repair file systems errors during the boot process. This is identical to Repair Disk in Disk Utility or the fsck_hfs -fy terminal command. So you should be able to find the text "Trimming unused blocks" in one of the fsck_hfs.log files.

 

[RS2]

In Safe Mode Mac OS X automatically verifies and repair file systems errors during the boot process. This is identical to Repair Disk in Disk Utility or the fsck_hfs -fy terminal command. So you should be able to find the text "Trimming unused blocks" in one of the fsck_hfs.log files.

If you have the MBP 2011 Mac OS X 10.6.7 you should be able to see this in the fsck_hfs.log in /private/var/log after a safe boot.

/dev/rdisk0s2: ** /dev/rdisk0s2
/dev/rdisk0s2: ** Root file system
/dev/rdisk0s2:    Executing fsck_hfs (version diskdev_cmds-491.6~1).
/dev/rdisk0s2: ** Checking Journaled HFS Plus volume.
/dev/rdisk0s2: ** Checking extents overflow file.
/dev/rdisk0s2: ** Checking catalog file.
/dev/rdisk0s2: ** Checking multi-linked files.
/dev/rdisk0s2: ** Checking catalog hierarchy.
/dev/rdisk0s2: ** Checking extended attributes file.
/dev/rdisk0s2: ** Checking volume bitmap.
/dev/rdisk0s2: ** Checking volume information.
[B]/dev/rdisk0s2: ** Trimming unused blocks.[/B]
/dev/rdisk0s2: ** The volume appears to be OK.

 

[Weaselboy]

In Safe Mode Mac OS X automatically verifies and repair file systems errors during the boot process. This is identical to Repair Disk in Disk Utility or the fsck_hfs -fy terminal command. So you should be able to find the text "Trimming unused blocks" in one of the fsck_hfs.log files.

I misunderstood. I thought you meant run from DU after safe boot.

I started in safe mode and sure enough the TRIM command is shown in the fsck log.

/dev/rdisk0s2: fsck_hfs run at Mon Apr 4 11:00:40 2011
** /dev/rdisk0s2
** Root file system
Executing fsck_hfs (version diskdev_cmds-491.6~1).
** Checking Journaled HFS Plus volume.
** Checking extents overflow file.
** Checking catalog file.
** Checking multi-linked files.
** Checking catalog hierarchy.
** Checking extended attributes file.
** Checking volume bitmap.
** Checking volume information.
** Trimming unused blocks.
** The volume Macintosh HD appears to be OK.

So if I understand correctly what is happening here, it would be a good idea for Cindori to encourage users (in first post) to do a safe boot once after install of the patch as this will TRIM free space... yes?

 

[RS2]

I started in safe mode and sure enough the TRIM command is shown in the fsck log. So if I understand correctly what is happening here, it would be a good idea for Cindori to encourage users (in first post) to do a safe boot once after install of the patch as this will TRIM free space... yes?

Hurray! Thanx for confirmation. Yes if you have the MBP 2011 Mac OS X 10.6.7 build with diskdev_cmds-491.6 the process would be:

1. Apply the Trim Support Enabler
2. Perform a Safe Boot to trim unused blocks
3. Change owner and group permissions on /
4. Update the prelinked kernel
5. Rebuild the caches for system kexts
6. Enjoy your trim enabled SSD!

 

[Cindori]

isnt Disk Utility "erase free space" already calling fsck?

also, the patch already runs steps 3 4 5

 

[RS2]

isnt Disk Utility "erase free space" already calling fsck? also, the patch already runs steps 3 4 5

Well erase free space will eventually trigger the trim function in the disk but I will not recommend that on a new SSD.

There is a new versions of fsck_hfs in the MBP 2011 Mac OS X 10.6.7 build. This is the only version with the trim unused blocks command.

I don't know why but step 3, 4 and 5 in your patch doesn't work. I and many others have to do it via terminal to get back the fast boot times.

 

[Weaselboy]

isnt Disk Utility "erase free space" already calling fsck?

also, the patch already runs steps 3 4 5

I don't think it can since the drive is still mounted when running DU.

The upside I see to the safe boot method of TRIM is it is far quicker. The erase free space in DU can take a long time on a large drive. It took around 30-40 minutes on my 120GB SSD. One safe boot then a restart will just take a minute or so.

 

[Cindori]

Well erase free space will eventually trigger the trim function in the disk but I will not recommend that on a new SSD.

There is a new versions of fsck_hfs in the MBP 2011 Mac OS X 10.6.7 build. This is the only version with the trim unused blocks command.

I don't know why but step 3, 4 and 5 in your patch doesn't work. I and many others have to do it via terminal to get back the fast boot times.

the steps do work but for some reason you need to redo the commands (or the patch) after Erasing free space in disk utility, perhaps fsck trim also then

 

[jenzjen]

I don't know why but step 3, 4 and 5 in your patch doesn't work. I and many others have to do it via terminal to get back the fast boot times.

Great job reading the threads and OP, there are many posts throughout discussing rerunning the patch to restore boot times. If I were you, I'd probably be less snappy given all the cindori has done here.