There is another option if the reliability, wear-leveling, and difference between write speed and read speed is of concern:
I have an Acard 9010 battery-backed RAM drive that I run Linux from. It will cost more to populate than the cost of the average SSD, but you get some advantages:
- Fast read speeds AND fast write speeds. SSDs have really fast read speeds and somewhat less faster write speeds.
- No wear leveling is needed.
- No concerns about full disks writing slower than empty ones as exists on SSD's
- Power blips are covered by the internal battery for about a day, and you can also use the external wall-wart for powering the ram-drive (in addition to the internal backup battery).
- Longer than battery life storage of your data is solved by the SD card built into the unit: once power is off, and battery voltage gets to a certain low level, the RAM-Drive backs up the contents of memory to a 64 GB compact flash card that is built-in to the front of the ram drive, then on power up, it copies the SD card data back to the Ram in the ram drive.
To directly answer part of the question, how to arrange partitions on an SSD (or RAM drive):
I put everything except
/home on the ram drive.
/home goes on a hard drive. It takes about 5 GB for Slackware64, so out of a 32 GB RAM drive, I have lots of extra space for development.
You do not have to do your work in
/home, though that is the normal "linux way", instead think about creating a directory in the Linux tree like
/projects which would be on your ram drive, setting permissions and ownership so your user will be able to use that directory and put your projects on the SSD/RAM drive for speed. Put your OS/tools/source code onto the RAM drive, work there, then have a shutdown script that copies your daily work to the hard drive.
As a belt-and-suspenders measure, I wrote a couple of simple scripts that back up the important user-created files that are on the RAM drive (or SSD) in case of trouble. Files like your
/etc/X11/xorg.conf that might be troublesome to get exactly right quickly (specially if you have a bunch of mp3 players in fstab, or a complicated monitor setup in xorg.conf, etc., in those files), if you had problems with SSD/RAM getting scrambled at any point.
I also have a pair of scripts that backup/restore every single file on the ram drive to a directory back on a hard drive, just in case. I mention those scripts because another answer mentioned the reliability issues with SSDs (or RAM drives). The scripts give me an extra measure of backup and easy recovery, should things go wrong at some point. Set up a chron job to backup several times a day if you wish, not a bad idea anyway.
So what I do:
/ on the SSD
/projects or other) for your work area, on the SSD
/home on a hard drive
/usr/scripts (created for user made scripts)
- scripts to backup user config files from SSD to hard drive
- scripts to completely copy the RAM drive to a hard drive.
The RAM drive has a .01 ms access time according to their website. It is much faster than a HD but not double (as someone said earlier).