Solid State Disk

Solid-state drives are high-speed, high-capacity Flash drives. Because of some of their properties, if you treat them like SSDs instead of like regular HDDs, you can increase their performance and lifetime.

Some rules to keep in mind

 * SSDs have a limited amount of writes, so you will not want to use them as swap, which needs a lot of writes (at least make sure you set /proc/sys/vm/swappiness to minimum, eg: 0 or 1)
 * SSDs have good random access (better than HDDs)
 * SSDs have high reliability
 * SSDs do not need special filesystems which spread the load across the drive, they often have their own controller and using a loadspreader anyway will actually hurt your SSD!

Limited writes
SSDs have a limited amount of writes, so you will want to compile in tmpfs, because compiling involves a lot of I/O. Make sure you have enough RAM.

Directories to mount elsewhere
There are some directories that are written too frequently, and/or are not read in normal, daily use. Here's a (probably not complete) list of directories:

/etc/portage/make.conf /etc/portage/make.conf
 * . Should be self-explanatory. You do not wan't to write your config files or your huge media collection on the SSD (although, this might change as larger SSD become cheaper or if you have loads of money to buy a few TBs of SSD). However, if there are static files on you home dir, that are accessed often, you might want to put them on the SSD and symlink to them.
 * firefox may be one of the biggest culprits here. Use lsof (see below) to see whom is writing most to / and /home, etc
 * One can use www-misc/profile-sync-daemon to move your profile to tmpfs while remaining in sync with the physical drive across crashes/reboots.
 * deluge writes to ~/.config/deluge/state/torrents.fastresume every 3 minutes or so. it's a 14M file on my system
 * One can move this file or directory to traditional storage, by using a symbolic link
 * when writes become less frequent lsof may not find them. Use   to find the most recent modified files
 * . Should not store anything permanent. Mount as tmpfs. No point having it in the SSD!
 * . Mount on a HD or a NFS. Will be written to at every 'emerge --sync'. Has a potential to become very large because of distfiles. Not read from except when emerging something.
 * set PORTDIR in to the new location, copy over the files, or emerge --sync
 * You most likely don't want to have your directory contained on an SSD at all, because it's used for variable information that means that data in /var directory is often changed. See the examples below.
 * . Contains at least /portage and probably /ccache subdirs. At least should not reside in SSD, preferably on tmpfs, but then you need a large swap partition or file somewhere (but not on the SSD!), if you intend to emerge something large. If you use ccache, mount it on a HD or NFS.
 * . Should also be self-explanatory. Logs are appended/overwritten all the time.
 * . All the information about all the packages installed by portage is stored there. Each time you emerge package =app-category/appName-appVersion, information about the package is (over)written in the /var/db/pkg/app-category/appName-appVersion/ directory.
 * . Default directory for layman overlays. In case you use layman, this should be treated as . Mount on a HD or NFS.

Depending on use case, some directories might not apply. This is intended as a list one needs to go through when making an SSD install. Other areas/programs may also cause writes to your main drive. To find these:

where sda is your primary drive that is or will become an SSD. the awk looks for write or update file handles. the above suggested directories are the most frequent writes in most systems, especially /var/log and /var/cache. but home dirs are also very frequently written by userspace programs to cache status. firefox and pulseaudio for example.

On systems with one solitary SSD, it won't be convenient to move the above suggested directories to another drive. However, one could use tmpfs. The issue is that these aren't retained across reboots nor after crashes. The logs are a huge problem for the latter.

Laptops
One very popular use for SSDs is in laptops. They offer lower power usage than HDDs, so your batteries will last longer between recharges, and your laptop will run cooler. SSDs are also much more shock resistant; dropping a laptop with an SSD is much less likely to hurt the drive than dropping one with an HDD.

However, most laptops only have one drive, so most of the above advice is not usable with an SSD in a laptop. One thing you do want to do though is put /portage in /var/tmp/, so be sure and have lots of ram in your laptop, or you will run out of space in /var/tmp when doing large emerges.

There is also one other possibility for courious ones. If your laptop has optical drive attached to notebook via SATA adapter, it is almost always possible to buy a replacement caddy capable of storing 2.5" SSD (or HDD) drive. Just search ebay for something like "SATA Hard Drive Caddy ". You can buy them for about 10$ and they allow you to replace your optical drive with brand new SSD. In such case I recommend putting SSD with linux system into the internal SATA slot so that you can use your linux install with optical drive in case you need it any day.

CCache
If you use ccache with portage, carefully consider where the cache is being stored. By default it is stored in, but if this directory is stored on the SSD you will be using the limited number of writes. This ccache can be moved in by adding the environment variable CCACHE_DIR=/var/tmp/ccache where  is a directory stored on either a traditional HDD or a tmpfs.

HDD/SSD combination
You can combine the speed of SSDs with the capacity of HDDs. To do this, the recommended setup is to save your root filesystem, and most importantly directories like, and , on your SSD, and save your media and high-capacity directories like  on your HDD. This way, programs can load very quickly using your SSD, but you can still save that 138GiB of media files on your HDD. An example would look like this:

Where sda is SSD, sdb and sdc are the HDDs. ''Question: didn't the recommendation above state that /var should not be on SSD at all? So why is /var on sda3 here?'' The noatime flag is highly recommended for SSDs (if not specified, every read access will update the access time stamp, leading to a write access even if files are not written to). The nodiratime behaves like noatime and will not update time stamp on directory access.

Scheduler optimization
On many sites you are suggested to use the noop scheduler with your SSD. While this might be true for the Intel X-25 drives which are optimized for random read/write operation, it is a performance killer for most other SSDs which are optimized for contiguous read/write (a lot of JMicron-based SSDs are). The cfq scheduler gives much better performance for these drives (NOTE: Is there a reference for this? I can't find anything via Google, except a lot of sites claiming one should use noop. Also, the above is not very informative for a given SSD brand/model, as it only specifically mentions Intel X-25).

.... Here are some refs, mentioning the issue described above, (sorry for my poor wiki skills)

AnandTech: Intel X25-M SSD: Intel Delivers One of the World's Fastest Drives

AnandTech: The SSD Relapse: Understanding and Choosing the Best SSD

ATA Trim
You should enable ATA TRIM if your filesytem supports it. This ATA command tells the underlying block device, mostly the SDD, which blocks are no longer needed and therefore can be overwritten. This allows the devices firmware to distribute writes evenly between blocks, increasing the lifetime and performance of the SSD. You can enable ATA TRIM under ext4 by adding the "discard" mount option. XFS has implemented it in Linux since v2.6.38. Btrfs will automatically detect the SSD and then start using ATA TRIM. LVM is able to pass through ATA TRIM, while Linux software raid is not.

Work to enable trim on encrypted partitions is currently underway, so support for TRIM on such setups is currently unavailable.