Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I've been booting and running my late-2012 Mac Mini using a Crucial SSD mounted in a plugable.com "lay-flat" USB3/SATA dock for more than two years now.

Still runs as good as the first day I set it up.

And -- something I consider quite significant in the discussions as to whether "TRIM" really counts for much with SSDs -- it's never had TRIM enabled (impossible with USB) and still runs as fast as when it was new.
 
  • Like
Reactions: circatee
I've been booting and running my late-2012 Mac Mini using a Crucial SSD mounted in a plugable.com "lay-flat" USB3/SATA dock for more than two years now.

Still runs as good as the first day I set it up.

And -- something I consider quite significant in the discussions as to whether "TRIM" really counts for much with SSDs -- it's never had TRIM enabled (impossible with USB) and still runs as fast as when it was new.

If the drive has a significant amount of free space, or plenty of time to run it's own garbage collection you probably wont notice a difference...
 
SSD configured and working...

DiskSpeedTest.png
 
  • Like
Reactions: wlossw
If the drive has a significant amount of free space, or plenty of time to run it's own garbage collection you probably wont notice a difference...

Depends, if the external connection type is USB but not TB, the "free space" have to be "free from the OS", that means those free space is never included in any partition after a "secure erase". Otherwise, since USB connection do not support TRIM, GC cannot use those "free space"(in the file system's point of view, they are free) and eventually the whole SSD will be "full" (in the controller's point of view, they are not free).

Therefore, after a long period of time, the SSD's writing performance may be reduced, because the controller has to do a lot of work when writing, but can't prepare the free cell in advance (by GC) during idle.

To alleviate this problem, either choose a SSD that has large over provision. Or create the over provision on your own. Which means "secure" erase the SSD, and then only create a partition that about 80% of the SSD's total capacity, leave the remaining 20% never touch (and cannot touch by the OS file system). In this case, the SSD controller now can confirm these 20% are free space (without TRIM), keep using them for GC, and prepare the free cell for future writing action.

The downside very obvious is that you loss 20% space straight away, however, since you should keep some free space on a SSD anyway, and you can actually use up to 100% on your partitioned space. Therefore, eventually, still more or less the same as partition 100% capacity with TRIM enabled but manually keep 20% free.
 
Last edited:
I havent, must say. Is working well here.
what setup doe you use?
[doublepost=1479414996][/doublepost]
I've been booting and running my late-2012 Mac Mini using a Crucial SSD mounted in a plugable.com "lay-flat" USB3/SATA dock for more than two years now.

Still runs as good as the first day I set it up.

And -- something I consider quite significant in the discussions as to whether "TRIM" really counts for much with SSDs -- it's never had TRIM enabled (impossible with USB) and still runs as fast as when it was new.

and have never had a freeze / hang?
 
I have a Samsung T3 that's been running for the last couple of months, nothing long term yet but its been solid so far.
 
  • Like
Reactions: cat40
To alleviate this problem, either choose a SSD that has large over provision. Or create the over provision on your own. Which means "secure" erase the SSD, and then only create a partition that about 80% of the SSD's total capacity, leave the remaining 20% never touch (and cannot touch by the OS file system). In this case, the SSD controller now can confirm these 20% are free space (without TRIM), keep using them for GC, and prepare the free cell for future writing action.


I know how to create a partition, for example I just secure erased a 275GB Crucial SSD. I then can add a partition of 55GB, but is there something special in formatting the 55GB. I don't understand the cannot touch by OS file system.
 
I'm guessing it was formatted for OS, versus FAT32 or NTFS, right?

I know how to create a partition, for example I just secure erased a 275GB Crucial SSD. I then can add a partition of 55GB, but is there something special in formatting the 55GB. I don't understand the cannot touch by OS file system.
 
I'm guessing it was formatted for OS, versus FAT32 or NTFS, right?

Yes Extended Journaled, But my question is if you create the 2nd partition after secure erase do you then eject it or do you keep it mounted and just don't use it?
 
Last edited:
Yes Extended Journaled, But my question is if you create the 2nd partition after secure erase do you then eject it or do you keep it mounted and just don't use it?

You need to erase that partition. It is done through Terminal. I don't have the code in front of me and can't seem to find it immediately online. I can post later unless someone else has it handy.

EDIT: I think this is it:

https://forums.developer.apple.com/thread/18776
 
  • Like
Reactions: cat40 and circatee
cat40 wrote:
"and have never had a freeze / hang?"

Nope.
No sleep problems, either.

I should mention that in experimenting with El Capitan, I was getting hangs and kernel panics at shutdown. After a long time of being frustrated with it, I discovered that the reason was because I had manually turned off memory compression during my setup. I turned it back on and the hangs/kp's disappeared...
 
  • Like
Reactions: cat40
I know how to create a partition, for example I just secure erased a 275GB Crucial SSD. I then can add a partition of 55GB, but is there something special in formatting the 55GB. I don't understand the cannot touch by OS file system.

NO, leave that 55GB NEVER partitioned (after secure erase). Because once partitioned, data may be written on it. And they are now managed by the file system. Without TRIM, the controller can't tell which cell's data can be destroyed and free it up for GC.

The whole idea is to leave that 20% space always free for the controller. And never belongs to any file system. So, the controller know it can be used that for GC without helping from TRIM. Technically, we just manually create a 20% over provision for GC to work properly without TRIM.
 
  • Like
Reactions: cat40
You need to erase that partition. It is done through Terminal. I don't have the code in front of me and can't seem to find it immediately online. I can post later unless someone else has it handy.

EDIT: I think this is it:

https://forums.developer.apple.com/thread/18776


Thank you Bent Christian, I read it but I am not confident enough to do anything with it. I deleted the one partition, I guess Ill just make sure not to use over 220GB of my 275GB on my external USB SSD and see how it goes.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.