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?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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.
Method 2
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.
Method 3
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
fstrimregulary (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
Method 4
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), various temps, some unessential logs 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 {start|reload|restart|force-reload|stop|status}'
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.
Method 5
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
Method 6
I am sorry, bad answers .Of course you can and should build a very fast system and still moving most written folders to HDD.
Move /tmp to /tmpfs or create /tmp partition on HDD also move to HDD and create symlinks on original folders for /var/log /var/spool and /var/tmp (don’t put /var/tmp on tmpfs as there is data that shoud be accessible across reboots). Move to HDD and create symlinks for ~/Downloads ~/Videos ~/Music ~/.config ~/.cache ~/.thunderbird ~/.mozilla ~/.googleearth ~/.ACEStream and others that you know or find out write frequent caches (always find where your specific browser cache is and move it to HDD Chrome and Firefox are covered with these ones I believe but check for yourself). If you need to edit a video file you can movee it to ssd otherwise 99% of documents and media have no benefict being in SSD. Also as HDD is far less used by systen these tricks have a negible impact on performance and huge difference in durability of SSD.
Move to HDD and create symlinks for your cloud folders (ex. dropbox).
Consider also moving /var/www if you’re apaching it.
Now you have a very fast system with almost no speed difference and with much much less wear out.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0