See discussion at Can I configure my Linux system for more aggressive file system caching?
In short, you probably need to have to tune some device queue settings. I'd guess scheduler or queue setting is incorrectly guessed by kernel or manually set.
Try
grep . /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth}
and
lsblk
to debug the issue. You should have queue_depth and nr_requests set to at least 31 if you can tolerate the latency for a single read caused by NCQ, nomerges should be zero and rotational should be zero for SSD. Selecting the correct scheduler will be harder but for raw IOPS noop should be good enough. I find correctly tuned cfq to handle real world requirements a bit better.
And make sure the disk is connected with SATA + AHCI and you have NCQ enabled. Otherwise, there is little hope for getting everything out from your disk.
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.
Best Answer
It seems like you've got the right idea. I'm going to assume that this is a home PC with a small number of users...
It can be a good idea to start completely fresh user profiles, in which case, you may want to create new user accounts, each with the same names and UIDs. It'd be easiest just to mount your previous
/homepartition, in/etc/fstabthough.If you create new user profiles on the SSD, then all the user-specific configuration files will be on the SSD, so logging in will be SSD-quick. The whereabouts of your home folder shouldn't affect boot-time, but would have a slight impact on the time taken to log in.
As you quite rightly said, you'll want to keep the media directories (Downloads, Videos, Pictures, etc.) on your other partition(s). I've found a pretty reliable way of doing this is to just create sym-links from the old media directories to your new home folder. If you had to do this for lots of users, this would quickly get tedious, unless you wrote a wrapper script around
useraddwhich creates the sym-links automatically.In terms of what sized disk to purchase, how much space are you using on your root partition now?
df -hwill show how much space is taken up by each partition. See this answer on askubuntu to get an idea of the space occupied by all installed packages.If you'll be using
dd, to duplicate your old root partition to the SSD, you'll need a new drive at least as big as the old partition. If you have hundreds of gigabytes of free space on your current root partition, you can shrink the partition using a tool likegparted, and that will allow you to copy the whole partition across, before expanding it to fill the drive.SSD drives are ideally suited for swap space, but I've already got an old swap partition, so I just use that. I see swap space as only strictly necessary in memory-limited emergencies, which I suffer very little from. YMMV.
Easiest solution? I'd just move the
/partition, and keep the rest as is. I find SSDs mainly flourish in terms of boot time and application startup time. With that in mind, you only really need/boot,/usr,/liband/varon the SSD; everything else can be elsewhere, with minimal effect on system performance.EDIT:
Another optimisation worth making on SSD drives is with the mount flags specified in
/etc/fstab. From the Arch Wiki and forum, on an ext4 partition, you might add:The
discardflag turns on TRIM support in the firmware;data=orderedoptimises journaling on supported file systems on SSDs;noatimeturns off recording files' last access time.