SSD in Older MB Pro?

The internal HD on my "17-Inch Early 2008" MacBook Pro has failed.
(Yes, of course I have a recent SuperDuper bootable backup, and I have
just cloned that to another drive, as well.)

This MBP is important to me and I'm thinking that an SSD would be a
good way to spiff up the speed a bit.

Can it use an SSD?

Any recommendations for an SSD larger than the 480GB models that seem
to be widely available? I'm thinking 1TB, and the Crucial M550 1TB
looks attractive at $525.

TIA!

 

Yes. The only catch is likely to be that OS X doesn't enable Trim
support by default with third party SSDs, and that feature might not
exist unless you are running a new enough version of OS X.

You need to use "Trim Enabler" (free unless you want the advanced
features) to turn it on, and will need to run it again after any OS
update because OS X restores its default settings.

http://www.cindori.org/software/trimenabler/

I see they have an older version which supports Snow Leopard. The
current version requires Lion or later.

The Crucial M550 has the advantage of protection against data corruption
on power loss. That might be an issue for an older MacBook Pro which
might have a battery that is wearing out or cannot be replaced (unless
you bought a spare battery before Apple stopped selling them - probably
too late now as that model was discontinued more than five years ago;
you might still be able to get one as a service part in California,
where the support limit is seven years).

In your position, the other one I'd consider is the Samsung 840EVO
series, which if I remember right has performance advantages (possibly
not achievable on an older Mac which doesn't have SATA III).

http://www.anandtech.com has useful technical reviews of SSDs, including
those two series.

 

Davoud:
David Empson:

Currently running 10.8.5 Mountain Lion. Software Update wants me to
upgrade to Mavericks. I assume it would not present that message if the
machine could not run Mavericks?

I've never heard of "Trim Enable." Is "Trim Enable" a necessity or nice
to have due to a speed advantage?

Luckily, I have two pretty good batteries. In any case, I don't run
this machine from battery; it's a desktop machine.

Thanks for taking time to post a most helpful reply.

 

As long as you know you will not get anywhere near the benefit of that
drive's full speed.

 

Most SSDs do not need TRIM enabled, AIUI.

 

This may be ok now but below is the kind of thing
that makes me wary - especially when it's just a
simple patch perl or any hex editor can easily do
(replacing "APPLE SSD" with nulls in the driver).

https://digitaldj.net/blog/2011/11/17/trim-enabler-for-os-x-lion-mountain-lion-mavericks/

| After a little inspection of this application,
| I found that instead of patching the file, it
| replaces an entire kernel extension. This means
| that when you use TRIM Enabler with Lion, it
| replaces a critical kernel extension, with lots
| of dependencies, with an older one (from Snow
| Leopard 10.6.8). This is bad. Very bad. While
| TRIM does become enabled, the kernel extension
| you now have has the potential to cause a ton
| of problems. That means anything from kernel
| panics, to disk I/O delays...and the dreaded
| spinning beach ball.
|
| After confronting the developer, Oskar Groth
| (who I refuse to link to), via his blog's
| commenting system, I was told that I was simply
| trolling and spreading fear (even though I
| offered the alternative I share here).
| Apparently, the next version of TRIM Enabler
| will correctly patch the file, instead of
| replacing it [...]

Billy Y..

 

Those using the SandForce controller won't benefit
much from it. Others, like Crucial (Marvell) and
Samsung will.

Billy Y..

 

In message <llmk1o$jct$>

That was true several years ago, but I am pretty sure I read something
about the current (SATA-III era) SSDs simply not needing TRIM.

I could be mistaken.

 

In this case, you can upgrade to Mavericks (there were no change in the
system requirements between Mountain Lion and Mavericks).

However, you assume wrong about where that particular message appears.
It is an advertising banner for Mavericks which is shown on the Updates
tab in App Store on every Mac not running Mavericks, whether or not the
computer is supported by Mavericks (several 2006-2007 models are limited
to Snow Leopard, several 2006-2008 models are limited to Lion).

This irritates me, because it might lure someone into the somewhat
complex process of preparing for the update (e.g. checking other
software compatibilty and maybe paying for software upgrades), going as
far as clicking the "Free download" button and trying to get Mavericks,
only _then_ to be told the computer isn't compatible, in effect pushing
them to buy a new Mac (or intensifying their annoyance with Apple).

Interestingly it appears that for the related "Upgrade to Mavericks"
alert which was added by "Mac App Store Update 1.0" back in March, Apple
was smart enough not to bug you if the computer isn't able to upgrade.
(From the one computer I've examined so far in this category, this is
achieved by Software Update never having offered that particular update
to older Macs unable to upgrade to Mavericks.)

Trim is a feature which aids for the longevity of solid state drives,
and often improves the performance after the drive has been used for a
while (you won't notice any difference for a new drive).

Due to their limited number of write cycles (per memory cell), the SSD
controller has internal logic which tries to do wear levelling by
avoiding having some memory cells written much more often than others.
This is complicated by the architecture of flash memory, which requires
erasing an entire page to write new data into previously written memory
cells within the page.

Typically the SSD controller keeps track of which portions of each page
are used, and if a page needs to be erased in order to reuse its free
space, the used portion of the page is copied to another page. This
tends to be done in the background by garbage collection when the SSD is
idle, unless it is getting seriously short on free pages.

Trim allows the operating system to tell the SSD controller when it is
deleting data in the file system, without the operating system having to
overwrite the data. This allows the SSD to treat the deleted area as
junk which can be discarded rather than needing to be included in
subsequent recopying during garbage collection, thereby saving
unnecesary wear on the SSD, and reducing the amount of time needed for
the internal copying.

Apple enables Trim if the SSD was supplied by Apple. They don't for
third-party drives. Trim Enabler makes a minor tweak to the OS to also
enable Trim for third-party SSDs.

You're welcome.

 

None of them really needs it, but every little bit of wear reduction
helps. TRIM is a SATA-only (and perhaps PCI) command. So Firewire,
USB, etc, disks have to live without it. SandForce compresses data
and that reduces wear for users with compressible stuff (probably
most people). More into is here -

http://www.lsi.com/company/technology/duraclass/pages/durawrite.aspx

Data Compression in the Intel Solid-State Drive 520 Series
http://preview.tinyurl.com/ow7274m

http://blog.lsi.com/did-you-know-hdds-do-not-have-a-delete-command-that-is-why-ssds-need-trim/
http://blog.lsi.com/can-data-reduct...im-in-an-ssd-and-drain-the-invalid-data-away/

Billy Y..

 

http://www.cindori.org/software/trimenabler/

[digitaldj.net/2011/07/21/trim-enabler-for-lion/ via Archive.ORG]
http://preview.tinyurl.com/oqdz962

Oskar Groth
August 27, 2011 at 9:01 PM

This script simply changes some data at an certain adress. If the
adress changes in a system update (which it did in Lion), this script
will overwrite the wrong data in the kext and probably corrupt it. I
pointed this out in my comments when you presented the script.

Not really the definition of safe.

Yeah I accused you of spreading fear, because you based your assumption
that my patch was dangerous on zero facts. Sure, you should not use old
kexts. But I made sure the patch had thourough testing in Lion before I
said "Ok, you can use it in Lion". And guess what... No one have had any
problems (that were not related to the trim itself not working optimally
for all drives). It could very well have been a bad idea, but I did not
make any recommendations before I could see it actually worked. The
reason I did not just update Trim Enabler with a Lion kext is because
kexts are actually illegal to spread, so I want to push for a kext-free
ultimate solution so I can get rid of it from my servers.

The new app (which does a lot more then just enable trim) will probably
be out in a week or two.

Grant Pannell
August 28, 2011 at 1:22 AM

Get your damned facts straight. You clearly show absolutely no
understanding of the commands presented. If you had any understanding
of how OSX kernel extensions actually worked, maybe you'd understand.
I explained why your method was unsafe in the post you deleted...but
in case you missed it, here it is again.

Firstly, the command DOES NOT patch a specific address. It searches
for the string "APPLE SSD" and sets it to null bytes (0x00). If the
string "APPLE SSD" is not present, nothing will happen. The script
will not touch the file. If you run the patch more than once, again,
nothing will happen because the string is not present.

If a system update occurs, the kernel extension will revert back to
original (i.e. no TRIM support). Applying the patch on a new version
of the file, that might have a slightly different offset will likely
have no disastrous effects. This is because:

a) If "APPLE SSD" does not exist in the file, THE FILE WILL REMAIN
INTACT. It WILL NOT become corrupt.

b) If "APPLE SSD" no longer triggers TRIM support, no harm done. It's
just a string. We're not patching assembly code to perform a different
task (i.e. jump to address or NOP instructions). We're not patching
static addresses in the file either, like what you're falsely claiming.
If ANYTHING, patching the string may have an effect on Apple specific
SSDs, who shouldn't be using the patch anyway!

Secondly, I wasn't spreading fear. I was spreading the truth and the
danger in using old kernel extensions with newer ones. I explained
exactly why in the post you deleted. Here it is again:

a) The kernel extension you were REPLACING is a base extension. There
are many other kernel extensions that DEPEND on the one replaced.

b) Since there are so many dependencies, you have no idea how these
other extensions will react when replacing it with an older version.

c) Kernel extensions are linked against specific kernel versions. Lion
has a new version of the kernel which is undoubtedly significantly
different from Snow Leopard.

In fact, if you go back and look at the comments on this post, forums
that ignorantly suggest your enabler, and hell, even your own post,
there are a ton of people having delayed I/O problems: the good ol'
spinning beach ball. There have been a ton of people claiming that
reverting the change fixes the problem, yet you have seemed to ignore
it. These are the exactly the sort of problems you expect to face when
downgrading a kernel extension.

You simply cannot claim to have tested it in Lion. There are too many
hardware configurations to claim that downgrading a highly dependent
kernel extension is safe.

Thirdly, you claim the address of the patch changes between system
updates. While this is true, the command to enable TRIM has not changed
since it's introduction in 10.6.8. It has ALWAYS been to patch out the
string "APPLE SSD" and this command has NEVER patched at a specific
address.

Fourthly, I simply cannot understand how it takes more than a couple of
hours to release a tool to run a couple of simple commands....unless you
don't really understand how the patch works to begin with. Hell, someone
has even commented on this post with a more friendly step-by-step
script. I have presented the 'raw' way of doing it, the way that can be
adapted for future version of the kernel extension without fucking
things up. Surely if you've realized that distributing an Apple kernel
extension is illegal, you'd want to quickly replace it with an
application that runs a couple of commands.

Oskar Groth
August 28, 2011 at 2:36 AM

Granted I don't know perl well, I based my claim on that when I tried it
with SL kext (where 'APPLE SSD' is at a different position), 'APPLE SSD'
remains. How come it does not work with SL kext if it just searches for
the string?

Yeah some people reported problems with beach ball, and problems
disappearing when reverting to No Trim. But since it's still the
same kext, I ruled out the kext as the issue...

Sorry if I came out as arrogant. If one does have problems with Trim
Enabler in 10.7.1 _both with and without Trim enabled_, replacing with
2.0 kext and using this script might be a good idea. I just have not
seen any such reports yet. Anyway I will try to have the new app ready
before 10.7.2. And no I am not spending time on making a script just for
trim, I want to make a general SSD utility, display smart info etc.

Grant Pannell
August 28, 2011 at 3:10 AM

In the case of the exact command above, Perl looks for 9 characters
(APPLE SSD is 9 characters) between the string "Rotational" (\x52\x6F
\x74\x61\x74\x69\x6F\x6E\x61\x6C\x00) and "Q", the start of the next
string (\x00\x51).

I have not looked at the 10.6.8 kext for some time, and I don't have
access to a copy at the moment. As for explanations I can only think
of two. Either the command has not been run as sudo and therefore
not touching the file OR, the 10.6.8 kext contains an instance of
"APPLE SSD" that is not between "Rotational" and "Q" and does not
need to be replaced to enable TRIM.