Ttyjfyk

I bought an SSD and I am going to set up my desktop system with a completely fresh Linux installation.

SSDs are known to be fast, but they have a disadvantage: The number of writes (per block?) is limited.

So I am thinking about which data should be located at the SSD and which at the HDD drive. Generally I thought that data that changes frequently should be placed on the HDD and data that doesn't change frequently can be put on the SSD.

• 
  

  Now I read this question, with a similar scenario. In the answers there is written: "SSD drives are ideally suited for swap space..."

  
  
  

  Why are SSDs ideally suited for swap space? OK, I see high potential for raising the system's performance, but doesn't swap data change frequently and hence there would be many writes on the SSD resulting in a short SSD lifetime?

  
  



• And what about the /var directory? Doesn't its contents change frequently, too? Wouldn't it be a good idea to put it on the HDD?




• Is there any other data that should not be located on an SSD?

If you worry about write cycles, you won't get anywhere.

You will have data on your SSD that changes frequently; your home, your configs, your browser caches, maybe even databases (if you use any). They all should be on SSD: why else would you have one, if not to gain speed for the things you do frequently?

The number of writes may be limited, but a modern SSD is very good at wear leveling, so you shouldn't worry about it too much. The disk is there to be written to; if you don't use it for that, you might just as well use it as a paperweight and never even put it into your computer.

There is no storage device suited for swap space. Swap is slow, even on SSD. If you need to swap all the time, you're better off getting more RAM one way or another.

It may be different for swap space that's not used for swapping, but for suspend-to-disk scenarios. Naturally the faster the storage media used for that, the faster it will suspend and wake up again.

Personally, I put everything on SSD except the big, static data. A movie, for example, doesn't have to waste expensive space on SSD, as a HDD is more than fast enough to play it. It won't play any faster using SSD storage for it.

Like all storage media, SSD will fail at some point, whether you use it or not. You should consider them to be just as reliable as HDDs, which is not reliable at all, so you should make backups.

Ok, so the goal is to get as much bang for the buck as possible - Speed vs. the price of replacement hardware (assuming a single large harddisk and medium-size SSD, which seems to be the norm). To simplify you can to weigh how much you notice the speed increase from moving a file to the SSD against the number of sectors written to move that file to the SSD.

• Files which need to be read a lot and written to rarely (such as the OS and programs) would probably be the most obvious to move to the SSD.


• Files which are written once and read to many times at a fixed data rate where the HDD is fast enough (for example music, video) should probably stay there. They are usually not modified, but consider that they are written to a lot of sectors.


• Small files which are modified a lot (such as some temporary files) are more complicated. For example, given a sector size of 512 bytes, you can overwrite a single-sector file 20,000,000 times before "consuming" the same amount of writes as writing a single 1 GiB file once. If the SSD takes care of wear leveling these should be equivalent.

Of course, even the best calculations also use up the most precious resource of all, time. So in the long run you're probably best off keeping it simple and buying new hardware slightly more often than the absolutely ideal case.

Agreeing with others, you should put pretty much everything except may be very large (video) files to avoid wasting expensive SSD space.

However, you should also make sure TRIM is enabled:

• Your SSD supports TRIM


• Your partition is aligned on a multiple of EBS


• Your file system supports TRIM on your file system (ext4 usually does)


• You run fstrim regulary (probably in a cron weekly)


• You keep at least 25% free disk space[1]

Remember to back-up your data.

UPDATE:

• 
  Arch recommends not putting the swap on SSD to avoid wear off

If you don't want to spend time to dispatch your data over HDD and SDD you may use your SDD as a cache.

• 
  L2ARC cache on ZFS (Solaris, *BSD)


• 
  Bcache (Linux) It is alpha code yet, so perhaps not reliable
  

Beside all the answers here there is a little tip I like. I have started to use ramdisk again with my SSD to slow wearing effect a little. I am using it for a browser cache (well whole browser profile), temps /var/log etc. (via symlinks)

My ramdisk is set in fstab as follows:

tmpfs /mnt/ramdisk tmpfs nodev,nosuid,size=512M 0 0

More RAM you have larger ramdisk you can use efficiently. With this I have boot/shutdown script. Various experience with writing ramdisk backup on encrypted device/folder even with lowest priority on boot and highest on shutdown.

This speeds up the system a little and saves some write cycles. Good thing may be a cron job doing rsync every 15 minutes?

#!/bin/bash

### BEGIN INIT INFO
# Provides: Ramdisk control
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 6
# Short-Description: Start/stop script at runlevel change.
# Description: Ramdisk auto backup and restore
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
USER="user1"
RDISK=/mnt/ramdisk
BACKUP=/opt/
#/home/$USER/BackUps/

#echo "$(date) $1" >> $BACKUP/rd.log

case "$1" in
 stop)
 rsync -aE --delete $RDISK $BACKUP
 ;;
 start|force-reload|restart|reload)
 #restore ramdisk
 cp -rp $BACKUP/ramdisk/* $RDISK 2> /dev/null
 ;;
 *)
 echo 'Usage: /etc/init.d/ramdisk reload'
 echo ' stop - backup ramdisk data'
 echo ' start|* - restore ramdisk data from backup'
 echo ' - default backup location is /xxxxx'
 exit 1
 ;;
esac


exit $?

Little warning for Ubuntu users, don't use /media/user/ folder for ramdisk backups as it gets resets by some updates so I was losing profile data periodically. Also with Ubuntu I had some difficulties making ramdisk bakups on encrypted home folder.