First Third-Party SSD With Native OS X TRIM Support Launched by Angelbird

[SeattleMoose]

"But unfortunately for users looking to install third-party SSDs into their machines, Apple only officially supports TRIM on Apple-branded SSDs. "

Is this because they are trying to big brother the user or .... profit driven?

 

[BurgDog]

"But unfortunately for users looking to install third-party SSDs into their machines, Apple only officially supports TRIM on Apple-branded SSDs. "

Is this because they are trying to big brother the user or .... profit driven?

Unfortunately this also effects third-party external drives where Apple does not compete. It is possible that Apple just doesn't trust its TRIM implementation on drives other than ones it can test it on. If TRIM is done wrong there could be serious data corruption. Maybe Apple doesn't follow the TRIM standards exactly and does something only its own drives can understand.

 

[0x0x0x0]

Looking at space used by OSX on the disks it uses (used disk utility partition map) it appears OSX doesn't randomly write the disk but expands usage from the beginning of the disk. This is consistent with a first fit strategy

This is non sequitur. In any case, HFS uses best-fit AFAIK…

also an attempt to keep mechanical seeks as short as possible. Looks to me to have a very high reuse likelihood of deleted blocks.

Since the transition to LBAs the OS has no idea of the underlying HDD mechanics, you can only "minimise" seeks if you know the exact CHS layout, which you do not.

Now whether or not the reuse occurs before GC is another question. Even then the lack of TRIM means a block with invalid data being moved is somewhat temporary as it will eventually get overwritten and reused and data in that block valid again.

You completely missed the point here- whether or not an invalid non-TRIMmed block will eventually get invalidated for GC purpose is irrelevant if GC has already scattered that garbage around the disk.

A much better test is for you to try the same "pattern" of usage over, say, a few months with and without TRIM, and then compare SMART 'Total Bytes Written' attribute for w/ and w/o TRIM.

I think over provisioning, and a high likelihood of reuse of deleted blocks reduces the benefit of TRIM, at least from a performance perspective.

Like I said before, TRIM is not just for speed.

I had an OWC 240GB in my Mac Mini that was about 75% full. I saw no measured performance drop after a year of normal use.

You seriously think you will notice a difference in performance when you're writing small files that most likely end up getting cached in SSD's DRAM cache prior to getting stashed on the flash chips?

----------

"But unfortunately for users looking to install third-party SSDs into their machines, Apple only officially supports TRIM on Apple-branded SSDs. "

Is this because they are trying to big brother the user or .... profit driven?

Most likely the latter- TRIM (being part of the ATA standard) capability is returned in the same ATA command as "APPLE SSD".

----------

So you could just replace the HDD, or put in two SSDs if you replace the optical drive as well?

Yes, but why would you want to do that?

 

[BurgDog]

This is non sequitur. In any case, HFS uses best-fit AFAIK…

Since the transition to LBAs the OS has no idea of the underlying HDD mechanics, you can only "minimise" seeks if you know the exact CHS layout, which you do not.

Every hard drive I am aware of maps logical blocks to CHS in a somewhat sequential cylinder order except for revectoring for remapped bad blocks. Keeping the logical block used range restricted also restricts the number of cylinders used. This, in general, reducing seek times. Even with a best fit strategy a desire to restrict logical block range means a significant amount of deleted block reuse. You don't need perfect knowledge of internal drive mapping to use heuristics that, in general, improve performance. Of course SSDs dynamically change the mapping to level wear, but the drivers were written for HDs first.

You completely missed the point here- whether or not an invalid non-TRIMmed block will eventually get invalidated for GC purpose is irrelevant if GC has already scattered that garbage around the disk.

But it won't get moved again the next time GC is done if it is overwritten in the meantime.

As long as there is sufficient over provisioning to handle the blocks that could have been trimmed but weren't until reused there should be no performance hit.

Like I said before, TRIM is not just for speed.

You seriously think you will notice a difference in performance when you're writing small files that most likely end up getting cached in SSD's DRAM cache prior to getting stashed on the flash chips?

I am only talking speed. I don't question the reduced wear benefits.

Some of those files were temp storage for large video files in the process of being compressed. Lots of deletion and rewriting of large files.

 

[lowepg]

It would seem the incentive for Apple for support 3rd party drives will continue to shrink over time as they release locked-down hardware.

"Want trim support in your SSD? Just buy the newest Mac...."

 

[henryonapple]

is anyone staying on mavericks because of this issue?

 

[0x0x0x0]

Every hard drive I am aware of maps logical blocks to CHS in a somewhat sequential cylinder order except for revectoring for remapped bad blocks.

Where did I refer to the drive itself? I was talking about the OS! Look:

Since the transition to LBAs the OS has no idea of the underlying HDD mechanics, you can only "minimise" seeks if you know the exact CHS layout, which you do not.

Keeping the logical block used range restricted also restricts the number of cylinders used. This, in general, reducing seek times.

Except that the OS has no idea where the boundary of one platter ends…

Even with a best fit strategy a desire to restrict logical block range means a significant amount of deleted block reuse. You don't need perfect knowledge of internal drive mapping to use heuristics that, in general, improve performance.

You give FS design too much credit- the heuristic is nothing more than "find the first place where this chunk of data will fit without excess"; there's no "let's keep seek to the minimum" logic. Of course it's completely useless in the cases where you're "streaming" data to the disk, e. g. downloading files.

Of course SSDs dynamically change the mapping to level wear, but the drivers were written for HDs first.


But it won't get moved again the next time GC is done if it is overwritten in the meantime.

As long as there is sufficient over provisioning to handle the blocks that could have been trimmed but weren't until reused there should be no performance hit.

I am only talking speed. I don't question the reduced wear benefits.

Some of those files were temp storage for large video files in the process of being compressed. Lots of deletion and rewriting of large files.

Actually, if you are just talking about speed, GC is not helping you, what is helping you is a giant (compared to the writes you do, and to the ones found on regular HDDs) DRAM cache/buffer that is located on the SSD.

----------

is anyone staying on mavericks because of this issue?

Not only because of the kext signing, but it is a serious contributing factor… On the plus side, you can just stick Mav inside a VM box ;-)

 

[dukebound85]

My point is that good garbage collection does not obviate the need for TRIM in all usage cases. For my own use, SSDs with excellent background GC do just fine, but those doing intensive video editing will have a different experience.

And yes Trim Enabler still works in Yosemite with a little tweak. Read the article.

I did...or did you not read when I said it doesn't work by default...

It's a little tweak that compromises security measures and something that should not need to be done....once again, why this story is news..

 

[BurgDog]

Where did I refer to the drive itself? I was talking about the OS!

You give FS design too much credit- the heuristic is nothing more than "find the first place where this chunk of data will fit without excess"; there's no "let's keep seek to the minimum" logic. Of course it's completely useless in the cases where you're "streaming" data to the disk, e. g. downloading files.

The OS only knows logical blocks, the drive does the mapping. The internal drive mapping fills a cylinder then seeks the heads to the next one. Cylinders cross all platters and are defined by a head position. Restricting logical blocks keeps seeks short and fast. An easy heuristic is start the search for best fit from LBA 0. This causes maximum reuse of deleted blocks while keeping seek range minimum. It also has the benefit of making it easy to resize partitions if all the content is at the bottom and filling upwards.

 

[DPUser]

is anyone staying on mavericks because of this issue?

I'm staying on Mountain Lion in my studio.

 

[Badagri]

I'm staying on Mountain Lion in my studio.

Have you upgraded Safari to 6.2? If you haven't, do not. Javascript is busted on it causing Safari to be very unstable.

 

[rGiskard]

Indeed, we definitely agree that a good GC in no way makes TRIM irrelevant.

Incidentally, according to an article on AnandTech, Micron's NAND smaller than 34nm is rated for 3k p/e cycles. Given that most "modern" SSD now use 20nm MLC chips, your assumption that only the low end SSDs have ca. 3k p/e cycles is unfounded.

At the end of the day, you need TRIM, GC just masks the problem but does increase the wear, and OS X is the only OS from main-stream OSes that doesn't "permit" trim on aftermarket SSD, even Android does it! And the problem is not technical one, as TRIM capability is reported in ndevice's ATA IDENTIFY DEVICE command, i. e. at the same time as the "APPLE SSD" string is returned.

That's true about the smaller process NAND having fewer P/E cycles. Better wear leveling, optimized GC, and increased spare area are all good strategies for dealing with it, but they don't entirely make up for the loss of endurance.

As far as the lack of TRIM, I think Apple just really hate to support third party upgrades. The good news (heh) is that in only a few years, TRIM support won't matter because no Mac will have the capability to be upgraded to an aftermarket SSD. This wouldn't bother me except for the fact that Apple insist on shipping Macs with HDDs, many even with 5400rpm HDDs! A few years ago I was sure all Macs would be using mini-PCIe blade SSDs by now, how wrong I was!

 

[Badagri]

As far as the lack of TRIM, I think Apple just really hate to support third party upgrades. The good news (heh) is that in only a few years, TRIM support won't matter because no Mac will have the capability to be upgraded to an aftermarket SSD. This wouldn't bother me except for the fact that Apple insist on shipping Macs with HDDs, many even with 5400rpm HDDs! A few years ago I was sure all Macs would be using mini-PCIe blade SSDs by now, how wrong I was!

 

[Hurda]

Respectfully, I understand your taking umbrage with Apple's lack of support for Microsoft's OS. Please let me know when MS adds native support for HFS+...

TRIM is a hardware-level-feature. HFS+/NTFS are not.
Don't confuse them to create an argument.

 

[Brian Buttplug]

it was in the article sort of.... 128GB for $99

Thanks mate, you are right

-Brian

 

[0x0x0x0]

The OS only knows logical blocks, the drive does the mapping. The internal drive mapping fills a cylinder then seeks the heads to the next one. Cylinders cross all platters and are defined by a head position. Restricting logical blocks keeps seeks short and fast. An easy heuristic is start the search for best fit from LBA 0. This causes maximum reuse of deleted blocks while keeping seek range minimum. It also has the benefit of making it easy to resize partitions if all the content is at the bottom and filling upwards.

Look, you said OS fills disk space from the start to keep seek times low, I said it doesn't because the OS has no clue about CHS layout. There's simply nothing more to that, no matter what way you try to spin your explanation. The OS simply has no clue what LBAs maps to "Cylinders cross all platters and are defined by a head position". OS can't care less where on the disk the data ends up physically (in terms of CHS), and it's been the case since about the later half of the 1990s.

----------

As far as the lack of TRIM, I think Apple just really hate to support third party upgrades.

I don't think it's a case of hating to support third party upgrades, as TRIM is already in the system and is part of the ATA standard. I suspects it's something entirely different… ;-)

 

[Menneisyys2]

is anyone staying on mavericks because of this issue?

The suggestion above (install an older OS X version on another partition and frequently boot in there to explicitly trim) seems to be workable.

 

[sundragon]

TRIM is a hardware-level-feature. HFS+/NTFS are not.
Don't confuse them to create an argument.

We're talking about supporting third party hardware so it's a valid argument. You may not like it, but they don't have to support third party anything if it means they aren't going to profit. This isn't rocket science, it's called capitalism.

 

[Menneisyys2]

We're talking about supporting third party hardware so it's a valid argument. You may not like it, but they don't have to support third party anything if it means they aren't going to profit. This isn't rocket science, it's called capitalism.

Then, it's also "capitalism" for us, customers, not to give Apple any money by just switching to OSx86 and Hackintohses. Which we wouldn't do if Apple didn't try to screw us up by, among other things, not allowing for TRIMing third-party SSD's.

 

[Badagri]

We're talking about supporting third party hardware so it's a valid argument. You may not like it, but they don't have to support third party anything if it means they aren't going to profit. This isn't rocket science, it's called capitalism.

So why did they make previous iMac's partially upgradeable and Mac Pro's fully upgradeable? It's like their UI. There were guidelines, now it's thrown out the window.

 

[soccerrocks314]

wholly hell,, I don't know there was an issue with SSD TRIM on macs! I've been shopping for a drive for months unaware of the issue.

What drives are good???
What drive with with TRIM?
---------------------------------------------------------

I can also back up the Samsung 840 Pro as being a great SSD. I have had it for over 9 months now and I have not regretted upgrading one bit! Quicker boot times and better overall performance when compared to the the stock HDD.

 

[Badagri]

Only for 3rd party. You have to buy an Apple branded SSD that comes with a new computer without add-on apps and disabling security features.

 

[ghostface147]

An SSD is the greatest thing I added to my early 2011 17" MacBook pro. Samsung evo 840 under Yosemite works great with trim enabler. It boggles my mind that they don't allow third party drives to use trim. They don't stop you from running third party memory...so why an SSD?

 

[mrf5]

I haven’t switch to Yosemite yet. but unless i'm missing something, I think trimming unused blocks once in a while should keep SSD in a good shape. at least (for now) this 'd avoid hacks that disable Kext signing .

fyi, to trim unused blocks (enter single mode) restart - hold down [cmd] & - type [fsck -ffy] (notice space before -) when done type exit to reboot.

 

[Badagri]

I haven’t switch to Yosemite yet. but unless i'm missing something, I think trimming unused blocks once in a while should keep SSD in a good shape. at least (for now) this 'd avoid hacks that disable Kext signing .

fyi, to trim unused blocks (enter single mode) restart - hold down [cmd] & - type [fsck -ffy] (notice space before -) when done type exit to reboot.

It should be running all the time. Not treated as a maintenance task.