Tangentially, if you are concerned about SSD wear, it might be worth your while to use something like SmartSleep to change the OS X behavior from "sleep & hibernate" to "sleep only".

The default OS X config will write the contents of your RAM to disk every time your machine sleeps. That means a 4GB or 8GB write every time you close the lid on your laptop. It's a much bigger hit than the Safari cache.

Is it really every time? I thought only when battery is low. Surely it takes longer to read/write 8GB, even on SSD, than speed of OS X's sleep/wake cycle.

Unless my understanding is badly flawed, it indeed is every time.

Once you close the lid, the screen goes dark, but the OS does write out the entire sleepimage file every time you sleep.

Yes AFAIK, its written on sleep every time, and only read back if the battery has drained and the RAM contents have been lost during the sleep (so most times you see the fast wake from RAM, and occasionally a tens of seconds wake from disk).

So the part that totally blows me away is that it appears to really write all of the contents of RAM out to the sleep image.

You'd think that the sleep image would omit the memory used for caching, but it doesn't seem to, i have a real 2.0GB file as my sleepimage.

I guess on a hard disk this is probably the correct optimization, but on an SSD it's not.

I guess you're right for the laptop Macs. I think the default behavior for iMacs and Power Macs is: sleep:machine will go to sleep only (saves state in RAM only, power supply keeps RAM contents).

Judging by the speed my 2006 iMac goes to sleep and wakes up (which is instantly).

"I guess you're right for the laptop Macs ... Judging by the speed my 2006 iMac goes to sleep and wakes up"

Yup. Disabling "sleep & hibernate" mode only applies for laptop Macs. However, the way to verify this is NOT by user perceptions of sleep and wake, since your Mac can still be doing writes after it's seemingly asleep.

The correct way to verify is to look for existence (or lack thereof) of the "sleepimage" file in /var/vm/

And my Mac Mini indeed does not have a sleepimage file, so I guess this is only an issue for laptop SSD users. (Disabling "sleep & hibernate" was the first thing I did when I got an SSD in my laptop.)

• The older assumes 100k cycles per cell, writing 3.4 Terabyte of data to a 160 GB SSD daily will leave your SSD functional for almost 13 years.
• The newer assumes 2 million cycles per cell, constant (sic!) writing at 80 GB/sec on a 64 GB SSD will leave it intact for more than 50 years.

Interesting article!

Still, it keeps puzzling me why there are a lot of users experiencing measurable slow down (on Mac OSX without TRIM support). Is this caused by the wear leveling algorithm for which it gets tougher and tougher to find unused cells??

If true, then reducing writes will still be beneficial to maintain write performance as long as Mac OSX does not support TRIM. So there are still other concerns than only the lifetime of an SSD to consider.

"Still, it keeps puzzling me why there are a lot of users experiencing measurable slow down (on Mac OSX without TRIM support). Is this caused by the wear leveling algorithm for which it gets tougher and tougher to find unused cells??"

Sort of--the key word here is "without TRIM support"--to my knowledge all the reports of modern drives experiencing slowdowns over time have nothing to do with wear leveling or failed cells, but with the lack of TRIM support meaning that the drive is having to re-write large blocks of data even for small amounts of data transfer. The reason that this problem exists (and the reason for TRIM support) area heavily documented if you read around.

So while slowdown is most certainly an issue, and it's even possible that web cache would exacerbate it, the lack of TRIM has more to do with it than any kind of wear issues. And it's important to note that just because cells in the SSD wearing out aren't likely to be a problem, that doesn't mean the drive isn't going to fail--just that it's not likely to be failed data cells that cause the drive to die. It might only last a year, or it might last ten, but it's going to be controller of full-chip failure that kills it, not data wear.

Note, also, that SandForce drives have better firmware to deal with the data slowdown issues than older (or, to my knowledge, Intel) drives. In particular OWC's drives have firmware that deals VERY well with the MacOS's lack of TRIM support--every real-world test I've seen of their drives show consistent read/write performance no matter how hard the drive is stressed.

"Those concerned about SSD wear should read this report: Press Resources Debunking"

Can we agree that there are many CONFLICTING reports being issued? There are also reports showing some bad real world outcomes with heavy wear on SSD's, and well as reports claiming it is a non-issue.

My take on the issue:

- I don't think the science is settled yet on this issue.

- I think this is a new technology where long-term issues will be discovered in the real world long-term.

- I think different manufacturers are experimenting with different solutions to the issue.

- I think folks involved in SSD manufacture and sales have an interest in pushing reports that take one particular side of the issue.

- In short, I don't think we yet know with anything even getting close to certainty about the long-term effects of heavy wear on SSD's.

So, I tend to take a balanced approach. I disable "hibernate & sleep" on my SSD laptops, since it's an ever-present source of VERY heavy writes. I try to leave my SSD's 50% empty to not put stresses on provisioning schemes.

Disabling "hibernate & sleep" doesn't bother me, since I can manage low battery situations on my own, without any real hassle.

Leaving my SSD's 50% empty doesn't bother me, since I don't need much local storage, because I keep my media on the LAN, and I can tunnel into my LAN when I'm traveling.

Those two steps seem like the low-hanging fruit to me.

Beyond those two simple steps, I don't worry. I don't put my Safari cache on a RAM disk. I don't change my behavior to avoid disk writes. I just enjoy the speed of my SSD.

Everyone is going to take different strategies, depending on their own needs. (If you're rich, don't worry, since you can just replace the SSD in 18 months. If you want to keep a machine with that SSD in it for 5 years, take some simple precautions, since the real verdict on the technology is in dispute.)

If there was a "Like" button here, and I actually had a facebook account, I would hit it. ;)

Flash cells have between 10-100K write cycles, so with 128GB of cells that's 1.2 to 12 PETABYTES of written data that the drive can handle.

Seriously, if you used 2mbit broadband, all piped straight to cache, 24h a day, for TEN YEARS non-stop you would only use 6% of lowest estimate of drives endurance.

I really wouldn't be worried about longevity of modern flash drives. Yes, they have finite lifetime, but so do spinning platters, heads and motors in HDD. I actually trust SSD more, as worn-out flash just becomes read-only, and doesn't have risk of catastrophic mechanical failures of spinning drives.

[ Reply to This | # ]

You are probably right about not being too concerned, but, of course when the drive fills up gradually the calculations is not correct anymore. The drive can do wear-leveling on a ever shrinking part of the SSD (say 60 GB of a 120GB drive).

Physical block allocation is not exposed to the OS, so the drive is free to swap contents of blocks in order to start saving to newest ones (although I'm not sure if OCZ controllers are smart enough to do that).

Modern SSD drives from Intel and anything with a SandForce controller (OCZ / OWC) no longer have the performance penalty over time. TRIM support is no longer required in the OS.

That being said, yes, you have fewer writes than you might with a traditional hard disk but the SSD should last 3-4 years for 90% of the folks out there. Some of these newer SSD's have a model meant for RAID which will stress the writes further. The SSD's for RAID are more expensive.

http://www.anandtech.com/show/2899/8 -> Lot's of detail in this review.

That being said, on a Mac, I moved my user folder to a traditional disk and keep the boot volume and applications plus my VM images on the SSD drive. I also clone the SSD weekly as I had one fail suddenly and without warning. It was warranty replaced, but all data was lost instantly!

The problem is not that SSDs have a performance penalty. SSDs will FAIL after a number of I/O operations. SSDs, along with all non-volitile RAM have a limited number of reads and writes before the gates within the chip lose their capacitance and stop holding the charge. The key is to limit the number of reads and writes to any NV-type RAM to extend its life.

In case of flash, number of reads/writes is practically infinite, only number of erase cycles is limited. You erase a cell, then write data to it until it's full. Reading doesn't wear it.

Indeed the two SSD "corruptions" I had thus far showed first after Google Chrome started to act strangely. The SSD (not sure which chipset, SuperTalent UltraTalent GX) was not damaged and it was twice a HFS+ corruption, one only solveable by formatting (thank you TimeMachine). I'm now giving this a try anyway, thanks for the nice script!

• Make sure you first create a directory with your short user name on the RAM disk, inside that you create the Cache Folder
• The link call given is the wrong way round AND missing the username, it must read (for Google Chrome):
  
  

  ln -s /Volumes/RAMDisk/[username]/Chrome ~/Library/Caches/Google/Chrome

  for Safari:

  ln -s /Volumes/RAMDisk/[username]/SafariCache ~/Library/Caches/com.apple.Safari

~/Library/Caches/Google/

 ~/Library/Application Support/Google/

Thanks for the correction you are absolutely right! These should be part of the hint, but it seems I cannot edit hints after they are posted.

I went in and made this change. Thanks for the corrections!

Great tip, I used to do this on Windows and it really speeded up my browser.

A question: as RAM prices continue to fall and Power Macs can support vast amounts of memory, would it not make sense to create say a 4-8 GB ramdisk and load more application files to it? If you have 16-32 GB of RAM, you can afford to dedicate a lot for this. And at current RAM prices, this is much cheaper than buying an SSD too.

Maybe I'm thinking about this too hard, but why not put the entire ~/Library/Caches directory on the RAMdisk? And why save it at shutdown? They're caches, right? Is there any harm in just letting them get rebuilt when necessary? Sure, the first launch of any app after a restart might be slower, but we've got an SSD to minimize that, and I don't restart very often anyway.

True, thought about this too. But, losing the cache on logout will mean you also loose stuff like your Safari preview thumbnails (it will regenerate them on launch via a relatively slow internet connection).

In case of a SSD, it will diminish the advantage you gain (fast app starts) because of the slower cache rebuilds (also counts for Word font cache, etc.).

$ du -ch ~/Library/Application\ Support/Google/Chrome | tail -n1
1,5G	 total
$ du -ch ~/Library/Caches/com.apple.Safari | tail -n1
756M	total

Safari only fills up till the Ram drive is full. So if there is no more space it will probably deleted the oldest cache entry and add a new recent entry. My Ram drive is 1GB of the 4GB inserted in my iMac which only supports 3GB anyway so no Ram lost at all.

I seriously doubt the number of writes is more when you have the habit of shutting down every time. Since my app uses rsync, it is smart enough to only sync changed files and not overwrite the whole backup every time at logout. All (over)writes in between do not add up to the SSD wear.

Thanks for the hint. But it doesn't appear that rsync is being called during a restart (only shutdown; not sure about log out?).

Is this really a valid concern, about the SSD drive wearing out in its lifetime? How many writes do you get before they become unusable?

By the way, Safari, like any program, is automatically going to keep often used data in RAM, not on the hard drive (if you don't believe me, open up Activity Monitor and see how much real memory Safari is using).

Hey, thanks for this!! Not only have I gotten a lot of useful opinions about SSDs, but this is a good example of creating a RAM disk in a Mac shell script AND making a shell script in to an app bundle.

All three are things I'm trying to learn more about right now.

This cool app can be adapted for firefox too, guide here:
http://snipeworld.com/2009/10/22/how-to-use-ramdisk-in-firefox-on-mac-os-x-10-5-leopard/
Thanks!

Hi,

With Snow Leopard, will a ram disk noticeably benefit browsing performance, either Safari or Firefox? (My current daily use is primarily browsing. I've a good 20+ download Comcast connection. Even when in Developer menu, I've disabled caches, I hear a bunch of drive activity. Activity Monitor seems to show a bunch of disk IO as well.)

As an aside... I've been considering getting a Seagate Momentus XT hybrid SSD 500G drive -- now that they seemed to have fixed things with their December ver SD24 firmware update. And probably will when I upgrade my drive for capacity. The drive has been available as low as $90., so if I wait for another promo, it's not a lot more than another 7200RPM 500G drive.

Thanks.

FYI: i had the Seagate you are thinking of getting and i wasn't happy with it. The speed was good but it had a lots of DULL moments when the HD would almost freeze. I did a firmware upgrade but the problem persisted. It was really annoying especially while watching movies.
i've replaced it with a OWC SSD :-)

Thanks. Do you recall if you tried the V24 firmware, posted in first half of December?

At CES a company announced an OEM HDD controller with SSD. Seagate should see some competition soon. Hopefully the drivers are fleshed out for this controller before they ship.

After reading this article, I stumbled across RAM Disk Utility Pro, a $15 shareware ramdisk from Taiwan. It creates a ramdisk and can create a file system link so that the Safari cache is redirected there. 64MB is plenty, and does seem to pep up safari a bit.

This is a great idea, I really want this to work, so I can cache things from my IDE and compiler output and what not, but unfortunately, I can't get it to store anything on log out.

It on 10.6.6 it appears that the shutdown function never runs.

if I run the script manually and SIGINT it will rsync but just logging out with the app in the Login Items doesn't store anything to the disk.

It reads what is there back in on login, but never stores any updates on log out.

I even tried adding more trap SIG stuff not luck.

# Shutdown: Register terminate signals.
trap shutdown SIGINT SIGTERM SIGEXIT

Hat's off to QuickSander for making Cache2RAM. I had little issues with it though, it failed to sync backups and restore ramdisk content upon logout. So, I've tweaked the script and made it work via Login/LogoutHook.

My script is 99% based on QuickSander's work. Just that it works like a charm for me, wanted to share. I'm using it on OS X 10.6.8 without any issues. Here is github link to the project -

https://github.com/ideamonk/Rambola

Cheers!

Why RamDisk lost when changing network?