Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

TRIM enabler issue with two SSDs

macstatic

macstatic

macrumors 68020
Original poster
Oct 21, 2005
2,059
176
Norway
I've been running TRIM enabler with a single SSD (Samsung 830, 128 GB) for a few months with no issues. A few days ago I added another SSD (same brand, type and size) and was surprised that it didn't show up in that application.
So I decided to turn TRIM enabler off, then on again, however I wasn't able to turn it on again! I got an error message saying something along the lines that I probably had an Apple SSD or something (which of course is incorrect). I figured it might have something to do with the second SSD, so using "Disk utility" I ejected the drive and tried again. No dice :confused:
Next I shut down the Mac, disconnected the SATA cable from the 2nd SSD and powered up the Mac again. This time I was able to enable TRIM enabler, so since then I've reconnected the 2nd SSD but haven't touched the on/off function of TRIM enabler.
So what's the deal? Why won't TRIM enabler support both SSDs?

The first SSD is my boot drive and connected to the lower optical drive connector. The second SSD is used as a Photoshop/Lightroom scratch and cache disk and is connected to a SATA-II PCIe card. I'm running OSX 10.6.8. Snow Leopard.
 
macstatic said:
So what's the deal? Why won't TRIM enabler support both SSDs?

The first SSD is my boot drive and connected to the lower optical drive connector. The second SSD is used as a Photoshop/Lightroom scratch and cache disk and is connected to a SATA-II PCIe card. I'm running OSX 10.6.8. Snow Leopard.
Click to expand...

So from that, it looks to me like you already know how to begin debugging this. No?
 
Have you tried removing the problematic TRIM enabler and trying an alternate (and far more reliable) method of activating TRIM?

http://digitaldj.net/2011/07/21/trim-enabler-for-lion/
 
Thanks for your suggestions.
Whilst searching for a solution I came across the usual for/against TRIM discussions where one posting aginst using TRIM was pretty alarming:

Apple locked TRIM support for a very good reason — their code works reliably with the SSD’s they’ve chosen to use and no others, because they have programmed in nanosecond-critical timing loops that match perfectly with the access timings of the controllers used in Apple’s SSDs. Using these drivers with other controllers can, at best, slow them down, and at worst, increase the thermal effect that kills storage cells by forcing the controller to act when it isn’t quite ready. This thermal increase hastens the death of the SSD, reducing the already-low lifespan down to six months, if not less.
Click to expand...

Read the complete posting/thread here.

I'm no engineer and thus have no basis for agreeing nor disagreeing, so the big question of course is what would be safest for my SSDs' health? Enabling or disabling? Many people say that TRIM is unnecessary for drives with built in firmware garbage collection (which my Samsung 830 drives have), others say TRIM and garbage collection complement each other. Personally I just want to see my SSDs last for a long time although with decent performance of course.
Why did Apple disable TRIM for non-Apple installed SSDs in the first place?
 
macstatic said:
Thanks for your suggestions.
Whilst searching for a solution I came across the usual for/against TRIM discussions where one posting aginst using TRIM was pretty alarming:



Read the complete posting/thread here.

I'm no engineer and thus have no basis for agreeing nor disagreeing, so the big question of course is what would be safest for my SSDs' health? Enabling or disabling? Many people say that TRIM is unnecessary for drives with built in firmware garbage collection (which my Samsung 830 drives have), others say TRIM and garbage collection complement each other. Personally I just want to see my SSDs last for a long time although with decent performance of course.
Why did Apple disable TRIM for non-Apple installed SSDs in the first place?
Click to expand...


Interesting paragraph. Of course only someone studied on the intricacies of the various types of solid state drives would know to comment accurately - so that leaves me out. :p

But can't you use the SSD till it seems sluggish and then turn on Trim for a day - maybe rewrite the contents or whatever helps it along - and then turn it back off?
 
Tesselator said:
But can't you use the SSD till it seems sluggish and then turn on Trim for a day - maybe rewrite the contents or whatever helps it along - and then turn it back off?
Click to expand...

Yes, you can. Not using TRIM will in no way permanently harm a SSD. The worst that can happen is write speeds might slow down.

If that ever happens, enable the TRIM hack, then command-s boot to single user mode and run the command "fsck -fy" (without the quotes). This will TRIM all unused space on the drive and restore write speeds. You can then disable the TRIM hack.
 
The fsck -fy command worked fine (it said something about trimming), but only on my boot SSD. The other SSD isn't available though (it's connected to a PCIe SATA card and it appears drivers have to be loaded first). I tried it in the terminal window after having performed a normal boot but only got some error messages:

fsck -fy /Volumes/Cache/
/Volumes/Cache/ is not a character device
CONTINUE? yes

** /Volumes/Cache/ (NO WRITE)

CANNOT READ: BLK 16
CONTINUE? yes

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
ioctl (GCINFO): Inappropriate ioctl for device
fsck: /Volumes/Cache/: can't read disk label
Click to expand...

By the way, is fsck -fy the same thing as clicking on "erase free space" in "Disk Utility"? As you can see below both SSDs can be accessed there, unlike when booting into safe mode.
diskutilcache.png
 
Last edited:
Perhaps TRIM only gets passed to drives on the native SATA ports or drives that operate natively without added drivers? Or your particular PCIe card is not passing/supporting the TRIM command?
 
macstatic said:
By the way, is fsck -fy the same thing as clicking on "erase free space" in "Disk Utility"? As you can see below both SSDs can be accessed there, unlike when booting into safe mode.
Click to expand...

No, they are not the same. fsck is a command that checks disk integrity and partition/folder structure as well as running TRIM on unused space.

The erase free space only does one thing. It makes a large, empty DMG file that fills the free space, then it deletes that DMG file. This also needlessly adds a SSD write cycle to your disk. The erase free space command also takes forever to run because that large DMG has to be created.

I have seen the issue you mentioned with trying to run fsck on secondary drives, and like VirtualRain mentioned, I don't believe it will work.
 
VirtualRain said:
Perhaps TRIM only gets passed to drives on the native SATA ports or drives that operate natively without added drivers? Or your particular PCIe card is not passing/supporting the TRIM command?
Click to expand...

I wish I knew. It's a Silicon Image SIL-3132 revision C. Does anyone else reading have the same card and know? Will all SATA PCIe cards give me the same problem or is it worth looking into getting another one (SATA-III and more ports would be nice).


----------
Weaselboy said:
No, they are not the same. fsck is a command that checks disk integrity and partition/folder structure as well as running TRIM on unused space.
Click to expand...
Can I run it normally via the terminal, or do I have to reboot into safe mode?


The erase free space only does one thing. It makes a large, empty DMG file that fills the free space, then it deletes that DMG file. This also needlessly adds a SSD write cycle to your disk. The erase free space command also takes forever to run because that large DMG has to be created.
Click to expand...
Ah! That's my experience exactly -I tried it and it took 25 minutes with my new 128GB drive which has 124GB free.
In comparison, the "old" boot SSD (also 128GB but with 100GB free) only took a few seconds to do with "fsck".

I have seen the issue you mentioned with trying to run fsck on secondary drives, and like VirtualRain mentioned, I don't believe it will work.
Click to expand...
If that's the case, how do I take best possible care of this drive? (which I've dedicated to be a scratch/cache drive for Lightroom and Photoshop.
 
macstatic said:
I wish I knew. It's a Silicon Image SIL-3132 revision C. Does anyone else reading have the same card and know? Will all SATA PCIe cards give me the same problem or is it worth looking into getting another one (SATA-III and more ports would be nice).


----------


Can I run it normally via the terminal, or do I have to reboot into safe mode?



Ah! That's my experience exactly -I tried it and it took 25 minutes with my new 128GB drive which has 124GB free.
In comparison, the "old" boot SSD (also 128GB but with 100GB free) only took a few seconds to do with "fsck".


If that's the case, how do I take best possible care of this drive? (which I've dedicated to be a scratch/cache drive for Lightroom and Photoshop.
Click to expand...

Could you move the drive once every few months to a SATA2 backplane connection, enable TRIM, force it to trim and move it back? Only other way is with some kind of Secure Erase periodically. But lots of folks like me run SSDs in RAID (which never has supported TRIM) without serious detrimental effects on performance. Depending on the SSD and its susceptibility to degradation over time with the workload you have in store for it, it may not be all that necessary.
 
Yes, I suppose I could do that although it would be a hassle.
I'm concerned about this particular SSD as it will do a lot of write cycles (being a cache/scratch disk) -need I worry?

So if I do connect the cache/scratch SSD to one of the internal SATA connectors every few months, should I simply turn on TRIM (using Trim Enabler seems like a quicker way to do it than enter the terminal commands as suggested earlier), then let the mentioned drive be idle for a while (which is when TRIM does its thing) and finally do an fsck?

How do I know when TRIM has actually done its garbage collection and I can perform the fsck command to do the final cleanup?
 
macstatic said:
Yes, I suppose I could do that although it would be a hassle.
I'm concerned about this particular SSD as it will do a lot of write cycles (being a cache/scratch disk) -need I worry?

So if I do connect the cache/scratch SSD to one of the internal SATA connectors every few months, should I simply turn on TRIM (using Trim Enabler seems like a quicker way to do it than enter the terminal commands as suggested earlier), then let the mentioned drive be idle for a while (which is when TRIM does its thing) and finally do an fsck?

How do I know when TRIM has actually done its garbage collection and I can perform the fsck command to do the final cleanup?
Click to expand...

If you do that, there is no reason to wait (idle) at all. The fsck command does it instantly and you are done.

Here is my concern though. From what I am reading here, you folks are having trouble running TRIM on the secondary drive, so your plan is to swap around and make put the slave drive in the master location the enable TRIM and run fsck? I assume you don't have the OS on this secondary drive, so I'm not seeing how this will work. Am I missing something.

All of that aside, IMO everybody is overly concerned about this whole TRIM issue. Every SSD I have seen has some sort of internal "garbage collection" scheme, and if left to idle this will run and clean up the drive, restoring performance. TRIM just does it at the OS level and in real time. I really don't think you are going to see any performance degradation over time by not using TRIM.

It would be interesting to see some read/write tests when new, then again after a few months usage with no TRIM. I suspect given some idle time, you won't see a difference.
 
Weaselboy said:
All of that aside, IMO everybody is overly concerned about this whole TRIM issue. Every SSD I have seen has some sort of internal "garbage collection" scheme, and if left to idle this will run and clean up the drive, restoring performance. TRIM just does it at the OS level and in real time. I really don't think you are going to see any performance degradation over time by not using TRIM.

It would be interesting to see some read/write tests when new, then again after a few months usage with no TRIM. I suspect given some idle time, you won't see a difference.
Click to expand...

I've done a lot of reading on a bunch of different sites on just this topic and yeah, pretty much everyone (~80%) experiences performance degradation after some period of time. Some folks say after only a month while others say 6 months to a year. The degradation is usually described as being about "half speed" and sometimes even a little less than half. Some models seem to suffer from the condition more than others. And finally ~90% of these folks agree that enabling Trim fixes the problem and brings it back up to like-new performance levels.

Myself, I don't use SSDs as 3 or 4 drive RAID0 is faster at everything even small file I/O, offers massive storage capacities, and is about the same price as a single SSD over or around 256GB. When 1TB SSDs are $200 I'll promptly change my tune tho! :) I guess I'll be waiting about 3 years for that. :p
 
Weaselboy said:
If you do that, there is no reason to wait (idle) at all. The fsck command does it instantly and you are done.

Here is my concern though. From what I am reading here, you folks are having trouble running TRIM on the secondary drive, so your plan is to swap around and make put the slave drive in the master location the enable TRIM and run fsck? I assume you don't have the OS on this secondary drive, so I'm not seeing how this will work. Am I missing something.

All of that aside, IMO everybody is overly concerned about this whole TRIM issue. Every SSD I have seen has some sort of internal "garbage collection" scheme, and if left to idle this will run and clean up the drive, restoring performance. TRIM just does it at the OS level and in real time. I really don't think you are going to see any performance degradation over time by not using TRIM.

It would be interesting to see some read/write tests when new, then again after a few months usage with no TRIM. I suspect given some idle time, you won't see a difference.
Click to expand...

A couple of things...

In some situations, the TRIM command won't get passed through from the OS to the drives controller... certainly RAID, and it would appear it also happens with some third party SATA cards that require drivers. To rectify this, all a person needs to do is connect the drive to any of the SATA connectors on the mainboard to be able to use TRIM. Doing this once very few months should restore performance.

As for Garbage Collection (GC), it can only work with the information it has. The problem with modern file systems and SSDs, is that the file allocation tables or equivalents are stored by the OS, not the drive. So when a file is deleted, it's entry in the allocation table is removed, but the OS will not inform the drive... it will simply reallocate the blocks later. So the drive has no idea what NAND actually holds data that needs to be kept vs what NAND blocks can be reclaimed. This had no impact on physical spinning disks because there was no write penalty. On SSDs rewritting NAND that has existing data stored in it, incurrs a R/W penalty and can degrade performance. So you can see, without some kind of information from the OS, SSD GC routines have no way of knowing what NAND blocks can be wiped and reused. TRIM solves this by periodically letting the drive now what blocks can be reused. So TRIM can be very helpful for effective GC on a drive that's had all NAND written to at least once. How long it takes for a drive to get into degraded performance depends mostly on how much data is written to it over any period of time.
 
VirtualRain said:
file allocation tables or equivalents are stored by the OS, not the drive. So when a file is deleted, it's entry in the allocation table is removed, but the OS will not inform the drive...
Click to expand...

So if the said files were passed to the trashcan then a "Secure Empty Trash" operation would essentially be the same thing as using Trim?

Interesting...
 
Tesselator said:
So if the said files were passed to the trashcan then a "Secure Empty Trash" operation would essentially be the same thing as using Trim?

Interesting...
Click to expand...

I'm not sure what a Secure Empty Trash does... I suspect it just overwrites the blocks with all zero's or one's and perhaps wouldn't help at all.
 
No. The 'Secure Erase' command does not write zeros. TRIM does not write zeros.

It's important to note that 'Secure Erase' command is an actual ATA command, https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

vs the ad-hoc 'secure erase' procedure that has been around since the advent of spinning drives which involves one or multiple passes to write over the drive.

Currently, there is no OS X-native way to issue the 'Secure Erase' command.
 
MatthewAMEL said:
No. The 'Secure Erase' command does not write zeros. TRIM does not write zeros.

It's important to note that 'Secure Erase' command is an actual ATA command, https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

vs the ad-hoc 'secure erase' procedure that has been around since the advent of spinning drives which involves one or multiple passes to write over the drive.

Currently, there is no OS X-native way to issue the 'Secure Erase' command.
Click to expand...

From the OS X Manual:

Secure Delete
When a file is put in the Trash and the Trash is emptied, or when a file is removed using the rm UNIX tool, the files are not removed from disk. Instead, they are removed from the list of files the operating system (OS) tracks and does not write over.

Any space on your hard disk that is free space (places the OS can put a file) most likely contains previously deleted files. Such files can be retrieved using undelete utilities and forensic analysis.

To truly remove the data from disk, you must use a more secure delete method. Security experts advise writing over deleted files and free space multiple times with random data.

Mac OS X Server provides the following tools to allow you to securely delete files:
  • Secure Empty Trash (a command in the Finder menu to use instead of “Empty Trash”
  • srm (a UNIX utility that securely deletes files, used in place of “rm”)

And when I examine the space it's not random, but all zeros. So even tho the manual says "Security experts advise writing over deleted files and free space multiple times with random data", Apple is writing zeros when "Secure Empty Trash" is selected (at least for the last pass). ;) I didn't test "srm" so I dunno if that's the same or not.



And i dunno what Trim does - thus I asked.
 
Last edited:
Tesselator said:
Yeah, zeros... Isn't that what Trim does tho?
Click to expand...

Right, so a secure delete which overwrites data with one's or zero's protects the recovery of deleted data but does not help SSD garbage collection since there's still no information provided to the drive's controller that the NAND blocks are released.

Secure deletion should not be confused with Secure Erase or TRIM.

TRIM tells the drive's controller what blocks it can free up and consider unused. This allows the GC routines to erase the blocks during idle time so that writes can be done to those blocks as if they were fresh... thus enabling full write performance. Without TRIM, the GC is potentially preserving a lot of data in NAND that's actually no longer needed... and when the OS wants to write to those blocks, due to the nature of NAND, it needs to first read the data and then write... the dreaded read-modify-write delay which reduces performance.

Secure Erase is like TRIM but effectively informs the controller to mark all NAND as free returning the drive to it's factory state. It's another way to restore performance, but is destructive to all data on the drive, and therefore only a good solution when doing a fresh install on the drive or repurposing it.

There's a good explanation of all these things here...
http://en.wikipedia.org/wiki/Write_amplification
 
Last edited:
MatthewAMEL said:
No. The 'Secure Erase' command does not write zeros. TRIM does not write zeros.

It's important to note that 'Secure Erase' command is an actual ATA command, https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

vs the ad-hoc 'secure erase' procedure that has been around since the advent of spinning drives which involves one or multiple passes to write over the drive.

Currently, there is no OS X-native way to issue the 'Secure Erase' command.
Click to expand...

Tesselator was referring to the "Secure Empty Trash" feature of the Finder, not the ATA command "secure erase", which are two different things. You can enable Secure Empty Trash in this Finder preference pane. Or you can command-right click on the trash can to do a Secure Empty Trash. When you empty trash with Secure Empty Trash, the area that contained the data is over written.

screenshot20130320at123.png
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back