New SL install on SSD; moving user files over

Question

I installed a new SSD and now have a fresh SL install up and running. I'd like to use the SSD for applications, and the older "regular" hard drive (still in the box) for user files. What would be the easiest way to get rid of all the application and SL stuff on the older hard drive, leaving it strictly for my user files (music, video, docs, etc.)? Should I just wipe the drive clean and pull the stuff in from Time Machine? Or is there some other approach to use? Thanks.

Answer 1

Michael Winner wrote:
The info on the "test" symbolic link directory I've created on the SSD indicates that it's an alias. Is that OS X shorthand for the symbolic link, or could I have actually created an alias rather than an SL?
If you are referring to the "get info" finder dialogue then yes - it calls links aliases, and also calls aliases aliases confusing if your trying to determine specifically which it is. I don't actually know how to create aliases from the cli - but ln is a generic nix tool so i doubt it would have been aded to that.
Ideally the only non-symbolic link folder remaining on the SSD will be the library folder, correct?
Within a user directory (like you said) yes - in my opinion, as the user library is more like an extended part of the system and apps than bulk user data. Some system and app performance will depend on the speed that files within the user library can be accessed.
I'm not going to do any web publishing, so I can drop the Sites folder entirely, correct?
I don't think there should be any harm in that - although the OS does default to that directory when enabling web sharing - not sure what the side effects of it not existing might be.
Earlier in the thread it was recommended that I create one user account entirely on the SSD, so that I'll be able to log in if the HDD gives me trouble. Thoughts on this? I've cloned the current, pre-symbolic link install on the SSD, so that should work as a fallback, no?
If the contents of a user directory are unreadable and even unwritable then the OS will still allow the user to log in - except it will get the default preferences. but in your case because you are keeping the Library on the SSD it wont matter if the HDD is there or not until you go and use the other directories... as all your preferences and caches etc are in your library.
Since you've been so generous...guess I'll ask if you have any other advice for getting this setup "right" and taking maximum advantage of the SSD.
There isn't much else to do that will make a vast amount of difference... The important thing is to remember is not to let it get filled up to much... try to keep it's default state as empty as possible. There are two reasons for this..
Firstly wear levelling; it is only effective on the free space - if you fill up almost all of your SSD with static data and then use the last remaining space for temporary data storage then it will wear out that remaining capacity comparatively quickly (the wear levelling mechanism can juggle the nand page allocation for pages being re-written - but for the most part the pages holding the static data aren't going to get any use.)
(take this with a pinch of salt - you can safely fill 3/4 of your drive and then use the remaining for temporary data, but it's healthy to keep in mind - only extreme cases are likely to wear out the drive very quickly)
Secondly performance: This is to do with garbage collection and 'TRIM' - i wont get into the details here but as you may already know SSD performance degrades with use as data is mixed into pages - this is a reversible performance degradation but it is exacerbated by lack of free space.
There are various articles and forum threads on the web to do with Mac OS tweaks for SSDs, but pretty much all of these are centred around increasing the life span of the SSD - or more specifically decreasing write amplification due to the number of writes opposed to quantity of data written.
One quick tweak that makes absolute sense to do is enabling noatime … as with most unix file-systems HFS+ will write the access time of a file to the file-system every time a file is read - this means one write for every read (check your activity monitor to see this, you will always see a write operation when there is a read operation). access time isn't exactly of great use and there are no effects from disabling it… to do so you can use this launch daemon:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.noatime</string>
<key>ProgramArguments</key>
<array>
<string>mount</string>
<string>-vuwo</string>
<string>noatime</string>
<string>/</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
What this does is add the noatime option as a default when the mount command is called for root
You need to save this as a unicode file in your /Library/LaunchDaemons directory and change the owner ship and group to root:wheel… but i've written simple mini script to do it all for you, copy and paste this into your terminal then enter your password and it will write it to the correct place for you:
echo '<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.noatime</string>
<key>ProgramArguments</key>
<array>
<string>mount</string>
<string>-vuwo</string>
<string>noatime</string>
<string>/</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>' | sudo tee /Library/LaunchDaemons/com.noatime.plist
sudo chown root:wheel /Library/LaunchDaemons/com.noatime.plist
if you ever wanted to disable it for some reason simply delete the file "/Library/LaunchDaemons/com.noatime.plist"
Other tweaks are mostly to do with creating ramdisks and moving certain system directories containing logs and temp files to them… however this is beyond the scope of a quick copy and paste script, you must understand specifically what you are doing so you can adjust the sizes of the ramdisks appropriately and make important files restorable (because ramdisks are volatile)
Personally i don't think doing this is worth the effort, also if you don't have masses of RAM… or usually make use of all of it anyway then theres a good chance your ramdisk will be paged out to a swap file which kind of makes it pointless.
Anyway - hope that helps, enjoy your SSD !