MacInTouch Amazon link...

SSD, Fusion and flash drives

Channels
Security, Products

Ric Ford

MacInTouch
I've been watching the price of 4TB Samsung SSDs, which have been a little too pricy for me and still are, but Amazon has one today for much less than I'd seen before:

Samsung 860 EVO 4TB 2.5 Inch SATA III $1,099.99

I don't know if this is a special or if there has been a big drop that I missed. List price was $1399.99 last I knew.
 


Last edited by a moderator:


I don't know if this is a special or if there has been a big drop that I missed. List price was $1399.99 last I knew.
When I want to benchmark Amazon prices or view their history, I use camelcamelcamel.com. It also provides a product-specific notification service for those willing to provide contact information.

(I have no affiliation with the site and use it anonymously.)
 
Last edited by a moderator:


Is the 860 EVO better than the 850 EVO for the Mac, or the defacto replacement? The 850 has been well discussed here, the 860 not so much.

Is the Micron MX500 still Mac-friendly for firmware updates?
 
Last edited by a moderator:



Well, OWC fails me again. When I tried to install Mojave, I was told that the firmware partition doesn't exist on my Aura SSD -- which I can believe, since there was a known problem installing High Sierra on it. In October 2017, I opened a support case with OWC, and the response was that I need to unplug everything from my Late 2013 Mac Pro, uninstall the Aura, put the original SSD back in, update to High Sierra on the original part, unplug everything, re-install the Aura then install High Sierra on the Aura.

Fast forward to June 2018, and I am getting an error that the firmware partition doesn’t exist on my Aura — well, duh, the firmware partition is on the original Mac Pro SSD, which, of course, is not installed.

I know that OWC solved the problem with an Aura hardware update, but they refuse to replace the defective part under their 3-year warranty.
 


Fast forward to June 2018, and I am getting an error that the firmware partition doesn’t exist on my Aura — well, duh, the firmware partition is on the original Mac Pro SSD, which, of course, is not installed.
Will the previous hack (upgrade macOS with the old SSD, then swap the Aura back and upgrade again) work here?

If it's looking for a firmware partition, might there be a way to clone that partition to the Aura in order to satisfy the installer?

Just asking....
 


Just to update on the problems I was having with the OWC Aura (as in previous posts). Bought this in Jan 2017; not working well by Sept (or at all with High Sierra). OWC offered a small discount on the new one that would work with High Sierra (so, pay twice to get a semi-working product, within the guarantee period). They kept the correspondence going till this year (after guarantee ran out) and only then said, "You bought it in the UK, not our problem."

Went back without much hope to vendors (UK Computers Ltd), who turned out to be stars; they argued OWC into a full refund, so I'm now happily running a couple of EVO 860s in an external case, and much the better for it. Let me just blow a fanfare for these folk at UK Computers - and a huge raspberry for OWC, a company I will not do business with in future under any circumstances. As RonL1138 has found, there's no guarantee any version of the Aura will survive the next OS or security update. Be warned!
 


Will the previous hack (upgrade macOS with the old SSD, then swap the Aura back and upgrade again) work here? If it's looking for a firmware partition, might there be a way to clone that partition to the Aura in order to satisfy the installer? Just asking....
Good question. It's a pain to unplug the 11 connectors from the back then reconnect them in the correct order for maximum bus throughput so that I can reinstall the old SSD to upgrade to Mojave. And I have no idea if it will even work after I put the Aura back in.

As for cloning the firmware partition, I would guess it's similar to cloning the Recovery partition, but Carbon Copy Cloner has a special function for the Recovery partition which I guess they will need to implement for the firmware partition in the future.

OWC had to redesign the Aura (renaming it to Aura X) to work natively with High Sierra, so I think there is more afoot than just some hidden partitions.
 


Couldn't find anything here with a quick search, so I'll ask directly: What is the recommended method for destroying data on an SSD drive? This is for meeting ISO audit requirements, so any procedures need to be able to be referenced and/or researched. Physical destruction isn't an option for Macs we want to reuse in the company, and it would be nice to be able to donate EOL Macs to schools after 3 or 4 years.

Looking around the InterWebs results in many confusing and contradictory answers, a lot of which are ineffective legacy responses based on spinning hard drive technology and management systems. For example, the old process of booting from an external drive, running Disk Utility to erase, repartition to x partitions, then repartition back to one partition probably has little to no effect on the recoverability of SSD data.

One of the solutions I've seen is to fully encrypt (i.e. wait for it to finish), delete any record of the key, then decrypt, then re-encrypt with a different key. At this point we'd boot into Recovery to erase the SSD and reload the OS. Could it really be that simple?
 


Ric Ford

MacInTouch
Couldn't find anything here with a quick search, so I'll ask directly: What is the recommended method for destroying data on an SSD drive? ... One of the solutions I've seen is to fully encrypt (i.e. wait for it to finish), delete any record of the key, then decrypt, then re-encrypt with a different key. At this point we'd boot into Recovery to erase the SSD and reload the OS. Could it really be that simple?
I don't have a good reference for ISO audit purposes, but, for what it's worth, a couple of notes:

If you FileVault-encrypt the drive initially, it should secure all the data (reasonably well), then if you erase the drive, re-encrypting it with a different password, that should wipe out the earlier data.

I use SoftRAID for certifying drives, which wipes out all data in the process - they have specific recommendations for SSDs:
Why do I need to certify a SSD with 2 or more passes?

Some of the controllers used on SSDs (Solid State Disks) use data compression to minimize the amount of data they have to write to flash memory. This allows them to minimize the wear on the flash memory and to attain much higher write performance when tested using benchmarking applications. (Most benchmark applications write blocks of zeros when testing the write speed of a disk).

The disk certify function in SoftRAID was written with these data compression SSD controllers in mind. Every pass of the disk certify function, except the last one, will write out a non-compressible random data pattern. This ensures that SoftRAID tests as many of the locations in the memory chips as possible.
 


You are correct that procedures used to sanitize "spinning rust" HDDs are not the best to use with SSD devices. I'd start with reviewing the NIST SP 800-88 Rev. 1 Guidelines for Media Sanitization available at https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-88r1.pdf. In particular look for the section on "Cryptographic Erase," where the idea is to lose/destroy the encryption key.

As Ric says, the "sanitizing" process is easiest if you encrypt the SSD drive before putting any user data on it. That way unencrypted data gets encrypted the first time it's written to the drive.

The sanitizing process then becomes reformat the disk drive, reformat/partition the drive and reinstall the operating system. This should lose the previous encryption key and render any data unreadable. There's an optional step to write patterns to the drive, but note that this increases the wear on an SSD.

Encrypting an SSD after data is stored on it is probably your next best path. Encrypt, reformat, reinstall. Just realize that because of garbage collection and wear leveling algorithms in the drive, there is a likely chance that unencrypted data may remain on the drive in those overprovisioned areas of the SSD.

Writing patterns to an SSD to erase the data suffers from the same issue with the garbage collection/wear leveling algorithms. It also increases the wear on the SSD.

Decrypting the drive after encryption is a waste of resources and time.
 


Thanks, Ric! Here's the best article I've found on the issue, which gives several possible procedures, including overwriting - https://apple.stackexchange.com/questions/6278/how-to-securely-erase-an-ssd-drive

The article implies that, due to the various firmware and controllers, plus Apple's limitations on destructive overwrites in Disk Utility, the easy option is the process I described: fully encrypt (i.e. wait for it to finish), delete any record of the key, then decrypt, then re-encrypt with a different key.

Another option they list that will slightly slow the SSD (but might make the auditors happier) is to overwrite the SSD twice in Terminal:
diskutil randomDisk 2 /dev/diskN

I suspect I'll go with a combination of the first for laptops that will be reissued within the firm, and both for laptops we want to donate to schools at EOL. But first, let's see what other folks have to say.
 


Couldn't find anything here with a quick search, so I'll ask directly: What is the recommended method for destroying data on an SSD drive?
Depends on the SSD.

If it supports the ATA secure-erase command, then run an app that can generate the command. It will erase all the flash cells, which is about as wiped as you can get. I don't think any such app exists for macOS, but I believe you can get flash drive images that will boot your Mac into Linux, where you can issue the command.

Another option is if the SSD supports TRIM. Reformat it with a utility that will TRIM away all of the free space. I believe Apple's Disk Utility does this for devices that support TRIM. This will mark all of the non-overwritten logical blocks as garbage so the SSD controller's normal garbage collection will purge them later. If you are concerned about someone hacking the SSD to read the garbage space, you can leave the drive powered but unused (one way is to hold the Option key at power-on and leave the Mac on the boot-selection screen for several hours), allowing the SSD controller to have lots and lots of idle time that it can use for garbage collection.

The TRIM approach is not ideal, however, because any data stored in unallocated flash cells (uncollected garbage) won't get erased. But the only way to access this data would be to replace the SSD controller's firmware or to remove the chips and access them directly. Unless this is a concern for you, the reformat-with-TRIM approach is probably good enough.

If even that fails, you can use the old fashioned approach of just writing zeros to every block. It will cause all of the flash cells not mapped to logical blocks to be marked as garbage. They'll get wiped whenever garbage collection takes place (see above). The downside to this (vs. the TRIM approach) is that it will take longer and won't be able to mark the newly-zeroed logical blocks as garbage.

Note that if you are concerned about someone installing special data-recovery firmware into the SSD controller or pulling chips, then the latter two approaches are probably not going to be acceptable, since you will have no way of knowing when the garbage blocks actually were collected and erased. If you're only concerned about someone running software to read the deleted file space, then any of the above will be fine.
 



Couldn't find anything here with a quick search, so I'll ask directly: What is the recommended method for destroying data on an SSD drive?
After doing a bit of reading, I think there are two viable options. The first is if the SSD has used full-disk encryption, or self-encryption from day one, then you can simply discard the encryption key, and all data will be unusable. Since Macs don't support self-encrypting drives, that means full-disk encryption, like FileVault 2. If, however, you have used it without FileVault 2 enabled, even if you add it later, or wipe the SSD and re-do it with FileVault, you can't be assured that the SSD controller is not hiding unencrypted data in currently unused cells.

The only way to be entirely sure is to use the ATA Secure Erase command. When this command is issued, the SSD controller is supposed to ensure that all data is securely wiped and not readable. You can read more about Secure Erase here.

This procedure seems reasonable for wiping a Mac's SSD using Secure Erase commands issued by the "hdparm" utility. You simply need to boot from a Linux disk. The Ubuntu installer includes a LiveCD mode that would work. So you could burn a DVD for that and use an external USB optical drive (if the Mac doesn't have one built-in), or figure out how to write it to a bootable USB stick. Or simply install Linux on a secondary or external hard drive and boot from that.
 


... and any SSDs you use in your business should have FileVault 2 (full disk encryption) in use anyway, because people do break into companies and steal equipment now and then.
 


Thanks again, everyone -- in particular Rockwell, David C and Todd B. It looks like starting FV encryption ASAP after creating the first user, then after recovery for reuse doing the following: erasing, loading a new OS and starting FV encryption with a different key should meet ISO requirements for internal use. For EOL donation we will have to see...they may require physical destruction.

If they get fussy then the suggestion to boot from a Linux partition on an external HD and running Secure Erase should work, even though it will wear / damage the SSD's performance a bit.
 




If they get fussy then the suggestion to boot from a Linux partition on an external HD and running Secure Erase should work, even though it will wear / damage the SSD's performance a bit.
Secure Erase will actually improve/restore SSD performance. You're probably thinking that Secure Erase means writing zeros to every cell, thus impacting the number of P/E (program/erase) cycles on the SSD. But Secure Erase is an end-goal, not a prescribed methodology. How that is achieved depends on the medium.

For HDDs, spinning magnetic medium, that may mean writing zeros or random data to all blocks. For SSDs, the SSD controller can achieve the Secure Erase goal more efficiently by simply resetting all the cells (including reserved or otherwise inaccessible cells) to the empty state, releasing any stored electrons. So this process does not add to the P/E cycles on the SSD, and also has the side effect/benefit of resetting all the cells' write performance back to the factory fresh state (all empty).

You can read more here.
 


Regarding wiping data from SSDs in macs, this Backblaze article pretty much goes with what was stated here.
Actually, the whole "Securely Erasing Free Space on Your SSD" section in that article is not only bad advice, but also ineffective advice. They're basically instructing you on how to invoke the Apple secure erase function via the command-line to use on SSDs; the exact thing that Apple intentionally removed from the GUI for SSDs. The reason why it was removed is because of what I mentioned in my last post: Apple's secure erase function assumes traditional hard disk drive magnetic media. Writing all zeroes to the media is not appropriate for SSDs. Not only does it unnecessarily add to the P/E wear, but it also doesn't secure any of the reserved areas (wear leveling, overprovisioning, etc.) of the SSD which are hidden from the host system by the SSD controller.
 


I have a Mac Pro 2013, but I wouldn't have bought it if I had known that the SSD would remain a unicorn format. (It is 500 GB in my machine.)

I am contemplating buying one of the Samsung 4TB drives. - Can I ask:
  1. What's the best way to move your home folder to such a drive?
  2. What would be a good enclosure for this drive?
Cheers
Nick
 


I recommend formatting the drive with FileVault encryption before you install the operating system on it.
Interesting idea! So for a returned Mac laptop that we want to redeploy, we'd boot in Target Disk Mode, erase the SSD, start FV encryption and wait for it to complete? Or would we need to unencrypt before booting in Target Disk Mode and let that complete before erasing and re-encrypting? Then as usual, we'd reinstall the OS and boot from the Mac laptop directly as usual to create the local admin account.
 


I recommend formatting the drive with FileVault encryption before you install the operating system on it.
Definitely a good idea. It will go much faster, since it's really quick to encrypt an empty volume, compared with encrypting data already present.

I don't think it will be any more or less secure, as long as you encrypt before you copy any documents to the volume. Sure, there may be remnants of unencrypted files left in the SSD's garbage space, but if that only contains files from Apple's installer image, you're not leaking anything that could cause a security problem.
Writing all zeroes to the media is not appropriate for SSDs. Not only does it unnecessarily add to the P/E wear, but it also doesn't secure any of the reserved areas (wear leveling, overprovisioning, etc.) of the SSD which are hidden from the host system by the SSD controller.
It is definitely bad from the standpoint that it takes a long time to complete, it burns write cycles and ends up creating tons of garbage blocks that need to be collected. But with respect to the reserved areas, any unmapped cells that contain data will be marked as garbage.

If you're going to continue to use the SSD afterward, then that garbage will eventually be collected. If you're going to get rid of it, then you might have a problem because there is no way to know when all the garbage actually has been collected. Many SSDs (like those sold by Crucial) state that garbage is collected during idle time, so if you can arrange to have the SSD powered but idle (e.g. sitting at the startup manager screen) for several hours, that would probably do it. But I don't think every SSD controller does this the same way, so you would definitely need to conduct some research before relying on that approach.

I am contemplating buying one of the Samsung 4TB drives. - Can I ask:
  1. Whats the best way to move your home folder to such a drive?
  2. What would be a good enclosure for this drive?
I know you can create users with home folders in non-standard locations using Server.app. I'm not so sure moving an existing home folder is a good idea, though, because installed software may be storing the path. Apps shouldn't do this - they should use API calls or environment variables to get the location of your home directory and store paths relative to it for files stored there - but there are plenty of poorly-written apps out there.

You may find it far more convenient to just create a folder on the new drive, change ownership (so it belongs to your account) and permissions as appropriate, and then just start storing documents there. If you like, you can move folders from your home directory and replace them with symbolic links that point to the new location - that should have minimal impact on software, although there's never a guarantee. Some apps (like Photoshop or iTunes) have preferences that will let you simply start using an alternate location for storage.

As for an external enclosure, it's been a while since I shopped for one. You will want to make sure it has a very fast interface, given the speed of any modern SSD. USB3.0 (at 5Gbps) is probably a minimum requirement. USB 3.1 gen 2 (top speed of 10Gbps) will be better. Thunderbolt (up to 10Gbps for TB1, 20Gbps for TB2, or 40Gbps for TB3) will be your fastest option, but will also be a rather expensive enclosure.

I wouldn't bother messing with eSATA - it tops out at 6Gbps and it's going to be hard to find a way to put an eSATA interface on a modern Mac.

I won't recommend any specific brands here because it's been too long since I went shopping for enclosures and the kind used by the drives I use today (Vantec NexStar 3 USB/FW/eSATA) are no longer manufactured and would not be fast enough for an SSD anyway.
 


More context: Bombich Software, the maker of Carbon Copy Cloner, has a good entry in one of its FAQs about when to encrypt a new drive:
I formatted my destination as encrypted, and it's bootable. Why do you recommend cloning to a non-encrypted volume first?

We generally recommend that people establish a bootable backup on a non-encrypted volume, and then enable FileVault while booted from the destination. Some people have discovered, however, that a pre-encrypted volume can (will usually) function as a bootable device. So why do we recommend the former? There are a couple notable differences between pre-encrypting the disk vs. enabling FileVault after booting from the not-encrypted disk. When you enable FileVault via the Security Preference Pane:
  • You get a sanity check that a recovery volume exists (this avoids spending lots of time copying files only to find out that the volume might not be bootable)
  • You get the opportunity to store a recovery key with Apple
  • You can unlock the disk with selected accounts
  • You get a nicer UI on startup to unlock the disk (e.g. it's similar to the LoginWindow interface), vs. a less-polished looking Unlock Disk interface
One drawback to enabling FileVault via the Security Preference Pane, however, is that changes to account passwords on the source volume aren't immediately reflected on the backup as far as unlocking the disk is concerned. The old account passwords would be required until you boot from the backup and specifically re-enable those accounts in the Security Preference Pane (at which time the disk's EncryptionKey is remastered).
Also, this OWC article came out a few days ago:
How to Securely Wipe the Data Stored on a Drive in macOS High Sierra
 


Ric Ford

MacInTouch
So for a returned Mac laptop that we want to redeploy, we'd boot in Target Disk Mode, erase the SSD, start FileVault encryption and wait for it to complete? Or would we need to unencrypt before booting in Target Disk Mode and let that complete before erasing and re-encrypting? Then as usual, we'd reinstall the OS and boot from the Mac laptop directly as usual to create the local admin account.
It's fairly easy and fast, but, yes, you'd need to boot in Target Disk Mode if you're dealing with an internal SSD*. What I recommend, using a recent Disk Utility (e.g. from Sierra):
  1. Choose the whole device (may be slightly tricky in Disk Utility).
  2. Erase the drive, choosing GUID and Mac OS Extended (Journaled)
  3. Choose the device again and click the Partition button.
  4. Click "+" to add a partition
  5. Click to select the partition and make it small (e.g. 1GB) with format Mac OS Extended (Journaled).
  6. Click to select the big partition, choose Mac OS Extended (Journaled Encrypted) and provide a password.
  7. Click the Apply button to format the partitions.
  8. If Disk Utility fails (because it's dismally bad software), try again until you succeed.
  9. Check that the main partition is truly encrypted (e.g. right-click on the volume in the Finder - the pop-up should have a "Decrypt" item).
  10. Install the macOS (and other files) on the encrypted partition. This process should create the Recovery volume for you, taking a bit of space from the unencrypted partition.
  11. Check that Apple's installer didn't decrypt the volume (this happened to me once).
*Or, as David Charlap subsequently reminded me, boot off an external drive (USB, FireWire or Thunderbolt).
 


Ric Ford

MacInTouch
More context: Bombich Software, the maker of Carbon Copy Cloner, has a good entry in one of its FAQs about when to encrypt a new drive:
I don't think it will be any more or less secure, as long as you encrypt before you copy any documents to the volume.
Two problems with that:
  1. If you, as recommended, migrate your old system at first startup, you've just shot yourself in the foot - it'll take forever to complete encryption, and the files will be unencrypted until that's done, and they may linger, unencrypted, in SSD blocks.
  2. Even if you ignore that advice, you'll have to create a new account on first startup, with password(s), Keychain, etc., etc., and all that will be unencrypted (and may be left in unencrypted state in SSD blocks, etc.)
 


Ric Ford

MacInTouch
As for an external enclosure, it's been a while since I shopped for one. You will want to make sure it has a very fast interface, given the speed of any modern SSD. USB3.0 (at 5Gbps) is probably a minimum requirement. USB 3.1 gen 2 (top speed of 10Gbps) will be better. Thunderbolt (up to 10Gbps for TB1, 20Gbps for TB2, or 40Gbps for TB3) will be your fastest option, but will also be a rather expensive enclosure. I wouldn't bother messing with eSATA - it tops out at 6Gbps and it's going to be hard to find a way to put an eSATA interface on a modern Mac.
A really simple, fast external SSD solution is a Samsung T5.

As I've noted in the past, Thunderbolt can actually be shockingly slower than USB 3! It depends on a variety of factors. But there's a good Thunderbolt to eSATA option: Akitio Thunder SATAGo. It's pretty handy (I bought one).

For external enclosures to accomodate a SATA SSD, Akitio's Neutrino U3 should be pretty good (I have a few of their products).
 


A really simple, fast external SSD solution is a Samsung T5.
I have been using the Samsung T3/5 series for a few years now and love them. I have one that holds my Lightroom catalog, the other my last four years of photos. I band them together, and use a couple of short USB-C cables to connect them to my iMac or MacBook Pro. I also found a decent hard case on Amazon that is small, but holds both of them and the cables.

The only thing I've run into is that the drives are so small that it's possible to snap the USB connector if you aren't careful; at least one friend lost his drive that way, although Samsung replaced it.
 


Well, OWC fails me again. When I tried to install Mojave, I was told that the firmware partition doesn't exist on my Aura SSD -- which I can believe, since there was a known problem installing High Sierra on it. In October 2017, I opened a support case with OWC, and the response was that I need to unplug everything from my Late 2013 Mac Pro, uninstall the Aura, put the original SSD back in, update to High Sierra on the original part, unplug everything, re-install the Aura then install High Sierra on the Aura.

Fast forward to June 2018, and I am getting an error that the firmware partition doesn’t exist on my Aura — well, duh, the firmware partition is on the original Mac Pro SSD, which, of course, is not installed.

I know that OWC solved the problem with an Aura hardware update, but they refuse to replace the defective part under their 3-year warranty.
Why gamble on any of OWC's SSD's. The Cruicial and Samsung SSD's work without fail. I have installed a ton of them with no issues whatsoever. What I have seen in reference to OWC SSD's should scare anyone into not buying them.
 


Why gamble on any of OWC's SSD's. The Crucial and Samsung SSD's work without fail. I have installed a ton of them with no issues whatsoever. What I have seen in reference to OWC SSD's should scare anyone into not buying them.
In the last three years I've bought at least 30 OWC SSDs and haven't had a single issue. A client has 20 that have been on 24/7 for 11 months. I have 6, 5 are on 24/7, 1 for over 3 years, another for over 2 years, the others for about 1 year.

Back in 2014 OWC's firmware updater bricked an SSD that came in a BlackBook I was given. Even though the warranty had expired OWC offered to replace it. Sadly I had already dissected it.

I also have a Crucial and a Micron that have been problem free. The Micron is in an HP laptop, it's been on 24/7 for nearly three years.
 


For SSDs, the SSD controller can achieve the Secure Erase goal more efficiently by simply resetting all the cells (including reserved or otherwise inaccessible cells) to the empty state, releasing any stored electrons. You can read more here.
I wonder how important is this quote from that article (asterisks mine):
"When an ATA Secure Erase (SE) command is issued against a SSD’s built-in controller that **properly** supports it"
 


you'd need to boot in Target Disk Mode if you're dealing with an internal SSD
Or boot the computer from an external (USB or Thunderbolt) drive.
Why gamble on any of OWC's SSD's. The Cruicial and Samsung SSD's work without fail.
If you're dealing with a laptop that uses a standard form factor (3.5", 2.5", NVMe, etc.), then that's great. If, however, you are dealing with one of Apple's proprietary designs (e.g. those in a MacBook Air), then I don't think you can get aftermarket SSDs from anybody else.
"When an ATA Secure Erase (SE) command is issued against a SSD’s built-in controller that **properly** supports it"
There have been some SSDs where the secure erase command is buggy or otherwise broken. I don't think any units currently sold fall into this category, but it would be important to find out about your own before relying on it.
 


Good news! High Sierra Patcher was able to install 10.13.5 on my original Aura without much fuss at all. I hope that it will be updated for Mojave when it's released.
Before I found High Sierra Patcher, I ordered an Aura X, which is supposed to be High Sierra-compatible. There is a note on the package that the thermal pad on one of the chips needs to be modified for different Macs. For one Mac, it needs to be removed, and on the 2013 Mac Pro (my machine), it needs an optional 21mmx21mm heatsink attached to it. This wasn't documented on the Aura X's web page, and Amazon doesn't sell this size heatsink. OWC's heatsink part number is on the package, and I went to order it from them. It's not that expensive, but the shipping doubles the price, and I have to wait a week for it to arrive.
 


Before I found High Sierra Patcher, I ordered an Aura X, which is supposed to be High Sierra-compatible. There is a note on the package that the thermal pad on one of the chips needs to be modified for different Macs. For one Mac, it needs to be removed, and on the 2013 Mac Pro (my machine), it needs an optional 21mmx21mm heatsink attached to it. This wasn't documented on the Aura X's web page, and Amazon doesn't sell this size heatsink. OWC's heatsink part number is on the package, and I went to order it from them. It's not that expensive, but the shipping doubles the price, and I have to wait a week for it to arrive.
James C in support overnighted the heatsink to me at no charge so I installed the Aura X and attempted to format and restore my Sierra and High Sierra volumes...
Why gamble on any of OWC's SSD's. The Cruicial and Samsung SSD's work without fail. I have installed a ton of them with no issues whatsoever. What I have seen in reference to OWC SSD's should scare anyone into not buying them.
After spending 3 days in a fight to the death with that Aura X (wouldn't mount, wouldn't format, wouldn't boot), they gave me an RMA and it went back for a refund. I purchased a 1TB Samsung "Original Apple SSD" from Amazon and had it up and running using a backup in about an hour.
 


My gold standard has been Samsung EVO for a few years ago. Are (all) Crucial SSDs really just as no-brainer, it-just-works, replacement internal Mac drives?
 


My gold standard has been Samsung EVO for a few years ago. Are (all) Crucial SSDs really just as no-brainer, it-just-works, replacement internal Mac drives?
My experience with Crucial SATA SSDs:

I've installed Crucial SSDs into a mid-2010 MacBook Pro and a 2014 Mac Mini with no apparent ill effects. The MacBook Pro recently underwent a Sierra to High Sierra upgrade with no issues (yes, including the conversion of the boot disk to APFS - no problems).

your milage may vary.
 



Ric Ford

MacInTouch
My gold standard has been Samsung EVO for a few years ago. Are (all) Crucial SSDs really just as no-brainer, it-just-works, replacement internal Mac drives?
For what it's worth, my experience with quite a few SSDs, mostly 2.5" SATA but also a few mSATA:
  • An old Samsung 840 EVO (Dec. 2013), ended up being problematic - not a good experience in the end, possibly aggravated by being without power for weeks/months
  • Samsung 850 EVO have been fine (several)
  • No problems with an OWC Mercury Electra 3G (Feb. 2012)
  • All my Crucial SSDs have been fine so far (knock on wood): M500, M550, MX100, MX200, MX300
  • Crucial's firmware updaters were more Mac-friendly at one point than Samsung's (Windows-only)
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts