Michal Čihař - Configuring system for SSD

Configuring system for SSD

I decided to upgrade my notebook to SSD disk. The disk replacement went easy, installed fresh Debian on it and now comes the tricky part how to properly tune system to use as much as SSD can provide.

The first obvious thing for me is changing IO scheduler. But which one to choose? Most of howtos seem to suggest noop or deadline, without stating benefits of each. For now I've chosen deadline, without string coninfidence, that I'm doing the right thing.

The next major part of tips includes removing filesystem journalling. Well I think journalling exists for good reason and disabling it won't help me much (no, I really don't want to wait for fsck after each crash).

The last tweak seems to be using tmpfs for any temporary data (/tmp) or even for logs. For /tmp it might make sense, on cost of loosing available memory (or swapping it out, what really does not help the SSD anyway). However I definitely don't want to loose my logs on every reboot.

Maybe I'm missing some bit, but the only important thing seems to be the IO scheduler.


djadala wrote on Oct. 3, 2010, 1:51 p.m.

other important things are:
- mounting file systems on ssd with 'noatime' option
-data alignment on 64k boundary when cretang partitions, lvm volumes, filesystems.

Christoph Anton Mitterer wrote on Oct. 3, 2010, 2:28 p.m.

One can also:
- put /var/run, /var/tmp on tmpfs (although I'm not sure whether that's worht it)
- reduce the commit time for the filesystem (mount options)
- put the browser cache on a tmpfs (that should be worth it, but it probably doesn't work out of the box)

Anonymous wrote on Oct. 3, 2010, 8:13 p.m.

Unless you have a very *bad* SSD, you don't need to worry about moving things to tmpfs or turning off journaling. You also don't need to worry about the IO scheduler; modern Linux kernels can figure out when they have an SSD to deal with, and they avoid unnecessary operations like minimizing seek distance. So, you can safely stick with CFQ.

You should follow the recommendation to use "noatime" regardless of whether you use an SSD or not.

wrote on Oct. 4, 2010, 3:34 a.m.

I have seen some suggestions for optimising partition and filesystem layouts to match erase block sizes on SSDs. But apart from that I don't think that there's much need to do things differently. As you note the benefits of logs apply equally to all storage types, and as Anon suggests noatime works well on spinning disks.

The number of writes has been steadily increasing in SSDs, although we aren't sure how much I think it's pretty safe to put logs on SSD. Putting /tmp on tmpfs is OK if you have plenty of RAM - but it may force you into swap earlier.

On my EeePC 701 I have a SD card permanently installed that I use for swap among other things. If the SD card wears out from too much swapping (which is probably unlikely as the system has 1G of RAM and is usually lightly used) then I can easily buy another. If the main storage wore out then I would have a serious problem.

wrote on Oct. 4, 2010, 2:15 p.m.

There is a wealth of info including optimization guides for both the SSD and Win7 at my site if it helps.