Yosemite and TRIM

[Ethosik]

No you are plain wrong. TRIM has nothing to do with defragmentation whatsoever. It only tells the ssd to clear certain NAND cells which is completely different than a defrag where data is moved around so it is not all over the place but neatly ordered on the drive (both ssd and hdd).


No it is completely correct. Defragmentation is done on the hardware layer thus the drive, not the filesystem. The only thing that is different is the reason for doing the defragmentation. Normally you'd do that to increase performance due to the way a hdd works. It's just not the only reason why you'd do a defrag and that is what the article is trying to explain. A fragmented filesystem causes all sorts of problems.


Because you mention it just about everywhere no matter if it makes sense or has anything to do with it or not. Wear levelling on an ssd is done via an algorithm at write time to make sure that each cell gets an equal amount of writes. Defragmentation is all about grouping files. This fixes a couple of problems like not having enough inodes and a slowdown of disk speed (read and write).


You really need to research what wear levelling is because the above shows that you have absolutely no idea what it is at all. There is nothing correct about your description of wear levelling!

What wear levelling does is make sure that cells are written to equally but it isn't very strict. It can't be because you also have data on the drive that just stays there. Those cells can't be written and thus not all cells will be written to equally. The ssd might have NAND cells but there is much more to it than just that. Fragmentation means that parts of files are everywhere and pages/sectors aren't filled up efficiently. What defragmentation does is grouping those pieces of files together and also fill those pages/sectors as efficiently as possible. In case of an ssd there could very well be different levels of fragmentation (at filesystem level which is what is being discussed in the article but also at NAND cell level) but one should definitely not mix them up.


No, not all cells are being used. Only those that are available (some are dead like bad sectors, some are already in use, some have already had a lot of writes, etc.).


Same here since every ssd out there has garbage collection by default which works about as good as TRIM does.


It is definitely not part of that discussion because, again, it has absolutely nothing to do with it. Bringing up carrots would be the same thing. Yet you keep going on about wear levelling as if your life depends on it.


You start flaming an article with complete misinformation. That's name calling. Talking about having a "nice attitude"...

Anandtech has some old but relevant articles about how an ssd works. They'll show you exactly how files are stored on an ssd. Very nice read and illustrative pictures.

Um, it does not matter if I mention it numerous times. If it does not relate to the issue, EXPLAIN it. Do not just say: "obsessed with X much?".

So all data on the SSD is always next to adjacent cells? There are no empty cells AT ALL between data? If I have a 512GB SSD and only use 100GB of it (deleting and adding stuff conatantly), I am NEVER touching the other cells? If so, then yes, I do not know what wear leveling does. It was my understanding that it makes sure each cell gets equal use. By that definition, you can have empty cells that WERE used before in between cells that ARE being used. In an SSD data cannot be SCATTERED around the drive?

If a HDD has data scattered around the drive to hell, you would say it needs to be defragged. Because it needs to move to get data, and that is a performance hit.

Wear leveling:
http://product.tdk.com/en/techjournal/archives/vol01_ssd/contents07.html
http://www.atpinc.com.cn/technology-Global_Wear_Leveling.php

The data sure looks scattered around to me. Again, if you saw that on an HDD, you would say it needs a defrag so the head will not need to spin as much.

So why doesn't OS X and Linux defrag SSDs?

 

[Pushpaw]

Just wanted to add a note about my own experience. I installed a Samsung 840 Pro in a Mac Mini a while back, and was using Trim Enabler right up until Yosemite came out. I (luckily) had read about the boot issues before I installed Yosemite, so I deactivated and uninstalled Trim Enabler before upgrading. This was back when Yosemite first came out. This machine gets a lot of use, and I have not noticed any impact whatsoever from not having trim running on the drive. This machine is also on pretty much 24/7, so my guess is that its own garbage collection is doing well enough.

 

[Ethosik]

Just wanted to add a note about my own experience. I installed a Samsung 840 Pro in a Mac Mini a while back, and was using Trim Enabler right up until Yosemite came out. I (luckily) had read about the boot issues before I installed Yosemite, so I deactivated and uninstalled Trim Enabler before upgrading. This was back when Yosemite first came out. This machine gets a lot of use, and I have not noticed any impact whatsoever from not having trim running on the drive. This machine is also on pretty much 24/7, so my guess is that its own garbage collection is doing well enough.

Back on topic: I have a similar situation. I have a 2010 Mac Pro and I have had SSDs in there for a while. I NEVER installed TRIM enabler and have not noticed any issues at all. They get a lot of use too. I have had crucial M4s, and several Samsung 840 Pros that never had any issues running without TRIM.

Maybe with the lesser quality brands or cheaper SSDs this might be an issue?

 

[Cindori]

Pretty. Who is your icon artist?

Thanks It's made by Kasian Marszalek

Back on topic: I have a similar situation. I have a 2010 Mac Pro and I have had SSDs in there for a while. I NEVER installed TRIM enabler and have not noticed any issues at all. They get a lot of use too. I have had crucial M4s, and several Samsung 840 Pros that never had any issues running without TRIM.

Maybe with the lesser quality brands or cheaper SSDs this might be an issue?

It's pretty hard to notice a gradual loss of performance on an SSD, but the performance drop is real. Check the benchmarks here (scroll down) for results on Trim/No Trim on the 840 Evo.

 

[dyn]

Um, it does not matter if I mention it numerous times. If it does not relate to the issue, EXPLAIN it. Do not just say: "obsessed with X much?".

Don't just reply to a post, read it first! I've already explained it numerous times why it has nothing to do with it.

So all data on the SSD is always next to adjacent cells? There are no empty cells AT ALL between data? If I have a 512GB SSD and only use 100GB of it (deleting and adding stuff conatantly), I am NEVER touching the other cells? If so, then yes, I do not know what wear leveling does.

The controller on the ssd decides where the data will be written. It has to know which cells are already used, which cells are marked as bad and it has to go through things like the wear levelling algorithm. It is never the wear levelling algorithm that decides where things go. You simply can't use cells that are already in use or marked as bad. Also, if you have an empty ssd that is larger than the amount of data you are going to write to it, it obviously won't touch all cells.

It was my understanding that it makes sure each cell gets equal use. By that definition, you can have empty cells that WERE used before in between cells that ARE being used. In an SSD data cannot be SCATTERED around the drive?

It tries to do that but that doesn't mean data won't be scattered around the drive. Data is written to available cells (the ones that are empty) and when the ssd does that it will use the wear levelling algorithm to decide which of the available cells to use.

If a HDD has data scattered around the drive to hell, you would say it needs to be defragged. Because it needs to move to get data, and that is a performance hit.

On an hdd the head needs to go back and forth to fetch the data. This is what is causing the performance issue. On an ssd something similar happens but since this device is so fast you won't notice it. Unfortunately performance isn't the only problem when you have a fragmented filesystem. Not having enough inodes to store data is another common thing.

So why doesn't OS X and Linux defrag SSDs?

Because they use different filesystems that don't fragment at all or just a little. Those filesystems are more robust when it comes to fragmentation. However, heavily fragmented filesystems in Linux will run out of inodes. If there are no inodes then the system can not save any data to disk. OS X has very little fragmentation and there is a system that defrags the filesystem. IIRC it is only triggered for stuff smaller than 20MB. Mostly they'll do the same when there is a hdd in the system (so no difference between hdd and ssd). It all depends on the filesystem used.

 

[Ethosik]

Don't just reply to a post, read it first! I've already explained it numerous times why it has nothing to do with it.


The controller on the ssd decides where the data will be written. It has to know which cells are already used, which cells are marked as bad and it has to go through things like the wear levelling algorithm. It is never the wear levelling algorithm that decides where things go. You simply can't use cells that are already in use or marked as bad. Also, if you have an empty ssd that is larger than the amount of data you are going to write to it, it obviously won't touch all cells.


It tries to do that but that doesn't mean data won't be scattered around the drive. Data is written to available cells (the ones that are empty) and when the ssd does that it will use the wear levelling algorithm to decide which of the available cells to use.


On an hdd the head needs to go back and forth to fetch the data. This is what is causing the performance issue. On an ssd something similar happens but since this device is so fast you won't notice it. Unfortunately performance isn't the only problem when you have a fragmented filesystem. Not having enough inodes to store data is another common thing.


Because they use different filesystems that don't fragment at all or just a little. Those filesystems are more robust when it comes to fragmentation. However, heavily fragmented filesystems in Linux will run out of inodes. If there are no inodes then the system can not save any data to disk. OS X has very little fragmentation and there is a system that defrags the filesystem. IIRC it is only triggered for stuff smaller than 20MB. Mostly they'll do the same when there is a hdd in the system (so no difference between hdd and ssd). It all depends on the filesystem used.

I did not say wear leveling has to do with whatever Microsoft does with SSDs. I said SSDs, in a data - cell usage view, are essentially fragmented (data scattered around, not sequential). There can be unused cells between used cells. The data placement does not matter on SSDs. On HDDs they do. If you take a look at the same data usage view on a HDD and see that the data is scattered around, you would say it needs to be defragged.

That was my argument. The article is too broad or too generalized. That was my whole argument about the article being badly written. It does SOMETHING to SSDs, but it does not move data around to be nice and sequential like HDD defrag operations do.

Cindori: That is a nice looking site. Did you develop that yourself?

 

[dyn]

It does SOMETHING to SSDs, but it does not move data around to be nice and sequential like HDD defrag operations do.

Duh, that's because it's entirely out of the articles scope. The article is about why Windows still runs a defrag on an ssd even though it disables the defrag program when it discovers an ssd in the system. There would be no point in discussing anything related to an hdd or other unrelated things like wear levelling, data being nice and sequential, etc.

 

[newellj]

Check the benchmarks here (scroll down) for results on Trim/No Trim on the 840 Evo.

Is the 840 EVO a special case? Mine (on a Windows machine) actually did slow down very badly over time. The updated firmware made a huge difference.

 

[grahamperrin]

… Those filesystems are more robust when it comes to fragmentation. …

Performance with HFS Plus can suffer badly, in some environments (including solid state), if the catalog B-tree becomes fragmented.

 

[crjackson2134]

Performance with HFS Plus can suffer badly, in some environments (including solid state), if the catalog B-tree becomes fragmented.

Indeed! It sure can. I have defragged my SSD and gained performance.

 

[dyn]

Performance with HFS Plus can suffer badly, in some environments (including solid state), if the catalog B-tree becomes fragmented.

That's why I said "more robust" and not "immune" or "unaffected" There is a major difference between them. No system is immune to fragmentation since it causes various problems, not just performance. Some are simply more robust than others, meaning that they have less problems or are affected less.

 

[grahamperrin]

Trim Enabler in context

… disabling of trim enabler. …

Please note, the stricter security does not target Trim Enabler.

The TL;DR? section of Trim Enabler and Yosemite | Cindori puts things in context.

Incidentally version 3.2.2 (3.2.2) here on Mavericks is outdated, but the app can not apply the update to 3.3; it's improperly signed.

 

[Ethosik]

That's why I said "more robust" and not "immune" or "unaffected" There is a major difference between them. No system is immune to fragmentation since it causes various problems, not just performance. Some are simply more robust than others, meaning that they have less problems or are affected less.

I am still not sure how fragmentation hurts with SSDs. That is why wear leveling is part of the discussion. Data is scattered around (so data is basically fragmented, just like if we were talking about HDDs. If a HDD has data scattered around like crazy, the response will be to run defrag).

If you DO run defrag, wouldn't wear leveling kick in again making it pointless? Or is there a way to make data on sequential cells?

 

[JamesPDX]

Apple’s AHCI SATA drivers, and kext signing w/ 3rd-party SSDs...

I am still not sure how fragmentation hurts with SSDs. That is why wear leveling is part of the discussion. Data is scattered around (so data is basically fragmented, just like if we were talking about HDDs. If a HDD has data scattered around like crazy, the response will be to run defrag).

If you DO run defrag, wouldn't wear leveling kick in again making it pointless? Or is there a way to make data on sequential cells?

It's not worth it. If I were buying a new machine, I'd be forced to BTO with Apple's SSD. Not ideal, but it's all choiceless-plus-disposable.

The risk of a "no boot situation" by enabling TRIM and something going wrong down the line makes this not worth it for my particular setup, so I must stay with Mavericks where I can have Cindori's product running without concern. My 840EVO SSD's firmware is up-to-date, so I think I'll relax for up to 6 months.

Be sure to back up!

 

[seecoolguy]

Please note, the stricter security does not target Trim Enabler.

The TL;DR? section of Trim Enabler and Yosemite | Cindori puts things in context.

Incidentally version 3.2.2 (3.2.2) here on Mavericks is outdated, but the app can not apply the update to 3.3; it's improperly signed.

maybe I worded it wrong... but it's still a pain. IF you do opt to disable kext signing, just to get trim enabler to function, then you put your OS at risk and yourself at risk of not being able to boot your mac if the PRAM is reset for some reason (troubleshooting, intentional or unintentional). it's on that page too.

I suspect that the vendor cannot properly sign the app as Apple may not approve the app via the mac app store too bad the function works really well in 10.9

 

[h9826790]

maybe I worded it wrong... but it's still a pain. IF you do opt to disable kext signing, just to get trim enabler to function, then you put your OS at risk and yourself at risk of not being able to boot your mac if the PRAM is reset for some reason (troubleshooting, intentional or unintentional). it's on that page too.

IMO, it's all about probability. The chance that unintentionally reset PRAM is low. Even though reset PRAM, it's not necessary can't boot. Quite a few users intentional do this test, and prove that they can boot the system after PRAM reset with TRIM Enabled. It's just no guarantee on trouble free in case of PRAM reset with kext signing disabled.

I use TRIM Enabler since I upgraded to Yosemite until now. Never have any issue with TRIM Enabler.

I do play around with my system (kext), I guess I do that more than most of the normal user (e.g. install FakeSMC on my Mac Pro). And still has no issue with TRIM Enabler.

So, I will say no need to worry about that too much. For normal usage, I guess the chance of a fail HDD make the Mac no boot is higher than TRIM Enabler. Even though that happen, it's quite easy to fix in recovery partition.

 

[grahamperrin]

No kernel extensions in the App Store

… I suspect that the vendor cannot properly sign the app as Apple may not approve the app via the mac app store …

"… a kext is not going to be delivered through the Mac App Store …"​

– WWDC 2013 Session 707 - What’s New in Kext Development - ASCIIwwdc​

 

[Apple_Robert]

If one is careful about where one downloads programs from, (re: MAS and direct from developer) and turns off Trim Enabler before installing OS X updates, the chances of there being a boot problem are small, in my opinion.

 

[dyn]

I am still not sure how fragmentation hurts with SSDs. That is why wear leveling is part of the discussion. Data is scattered around (so data is basically fragmented, just like if we were talking about HDDs. If a HDD has data scattered around like crazy, the response will be to run defrag).

If you mean the Windows thing: it's not the underlaying hardware that is the problem. The problem is in the OS/filesystem so on a software level.

If you DO run defrag, wouldn't wear leveling kick in again making it pointless? Or is there a way to make data on sequential cells?

Fragmentation means that data is not only scattered all over the disk but also very inefficiently due to pages/sectors not being completely filled. Defragmentation will not only sort files but also make more efficient use of pages/sectors. The wear levelling will kick in but that's only because of the fact that you are writing data to the disk, not because of defragmentation (this is what will always happen no matter the reason for writing to disk, hence why I said it has nothing to do with defragmentation). An ssd will not have noticeable performance problems when the data is scattered over the disk nor when the pages aren't efficiently used because an ssd is just too fast.

If one is careful about where one downloads programs from, (re: MAS and direct from developer) and turns off Trim Enabler before installing OS X updates, the chances of there being a boot problem are small, in my opinion.

Experience teaches us that turning it off prior to updating is something that is very easily forgotten. Since you can start software update from the commandline it might be a good idea to script it and use that script to update the software. The script will first disable/uninstall TRIM Enabler then run the software update and apply the updates (if there are any). Now you only need to remember to use the script...

 

[Apple_Robert]

If you mean the Windows thing: it's not the underlaying hardware that is the problem. The problem is in the OS/filesystem so on a software level.


Fragmentation means that data is not only scattered all over the disk but also very inefficiently due to pages/sectors not being completely filled. Defragmentation will not only sort files but also make more efficient use of pages/sectors. The wear levelling will kick in but that's only because of the fact that you are writing data to the disk, not because of defragmentation (this is what will always happen no matter the reason for writing to disk, hence why I said it has nothing to do with defragmentation). An ssd will not have noticeable performance problems when the data is scattered over the disk nor when the pages aren't efficiently used because an ssd is just too fast.


Experience teaches us that turning it off prior to updating is something that is very easily forgotten. Since you can start software update from the commandline it might be a good idea to script it and use that script to update the software. The script will first disable/uninstall TRIM Enabler then run the software update and apply the updates (if there are any). Now you only need to remember to use the script...

Good point.

I am not a scripter. Outside of opening a cold one, I wouldn't know where to start. lol

If i understand you correctly, the script would bypass the need to reboot the computer, in order for the Trim Enabler change to take place?

 

[RichardC300]

It's pretty hard to notice a gradual loss of performance on an SSD, but the performance drop is real. Check the benchmarks here (scroll down) for results on Trim/No Trim on the 840 Evo.

Is the performance loss over time irreparable? Would enabling TRIM periodically repair any damage done from having it disabled?