Translation(s): none

This describe SDD optimization with system having encrypted root and swap.

/!\ An important aspect in optimizing SSD performance is the file system and partition alignment (1 MiB borders aligned to the 4096 byte blocks of the hardware). This wiki page does not cover these issues.


Partitioning Scheme

A commonly recomendable setup for serious work on a desktop/laptop:

If /var is kept on a persistent ramdisk (or only directly on the HDD) to avoid excessive wear on the SSD, a failed ssd can be fully reconstructed from HDD, but a failed HDD can only be fully reconstructed from the external HDD mirror or a backup. (Nevertheless, the presented scheme still allows to reconstruct your latest work-data from the SSD if the internal HDD failed.)

350MB boot-fs (md0 on /boot): If you want to encrypt the rootfs you need to encrypt the swap partition, and create this separate 350MB boot-fs (md0).

Workaround: mdadm {--fail, --remove, --add} /dev/mdX --write-mostly /dev/sdXY

20GB root-fs (md1_crypt on /):

or 5GB home-fs (md1_crypt on /home): Even if you do not want a raid mirror for the boot- and root-fs, you may still want at least a small separate home-fs raid, because it allows to reduce HDD spin-ups without the general write buffering risks: The HDD can be removed (or write buffered) separately if on battery, while updates are still written to SSD imediately. Create the home-fs raid with a few GBs mounted as /home, to contain (mostly only) the configuration files, lists of most recently used files, desktop (environment) databases, etc. that don't warrant to spin up the hdd on every change. Then you may be remove the hdd from that raid if on battery.

Still, even if you can prevent hdd spin-ups with this, to reduce the wear on the SSD caused by programs that are constantly updating logs, desktop databases or state files etc. in /home, you will have to use a persistent ramdisk (see profile-sync and goanything below) for those files (or the complete /home).

100GB work-data-fs (md2_crypt on /mnt/work-data) Using this only for /home/*/work-data allows to keep this raid mirror fully active while the hdd in the root-fs or home-fs raid is write-buffered or disabled. Thus writes to most recently used lists, browser caches, etc. do not wake up the hdd, but saving your work does.

15 GB var-fs (md3_crypt on /var) It allows you to see how variable /var actually is, by experiencing hdd spin-ups in addition to when saving to work-data (even if the root-fs/home-fs HDD raid members are write-buffered/disabled).

Large bulk-data-fs (/mnt/bulk-data):

Reducing writes to solid state disks "SSDs" or (laptop) hard disk drives "HDDs"

To stop constantly changing files from hitting on the ssd directly:

Use a throwaway /tmp ramdisk (tmpfs), to completely avoid unnecessary writes: debian: Set RAMTMP, RAMRUN and RAMLOCK to "yes" (in /etc/default/rcS or /etc/default/tmpfs since wheezy) ubuntu: /etc/fstab: tmpfs /tmp noatime,nosuid 0 0

Use persistent ramdisks (dedicated read/write RAM buffer that gets synced periodically and on startup/shutdown) to accumulate sdd-writes and hdd spin-ups.

With anything-sync-daemon or goanysync set up:

Options to having logs copied into RAM:,, (if it supports this), or

If /home is not on a persistent ramdisk, use profile-sync-daemon to have the browser database and cache copied into RAM during uptime (

Further improvement: Patch anything-sync-daemon or goanysync to use a (copy-on-write) union filesystem mount (e.g. to keep changes in RAM and only save to SSD on unmount/shutdown (aubrsync), instead of copying all data to RAM and having to sync it all back.

Alternatives to persistent ramdisk:

Optimized IO-Scheduler

Install sysfsutils and

(adjust sdX to match your SSD) reboot or

Other Options for SSDs

The performance of SSDs can also be influenced by these:

Note that using discard with on-disk-cryptogrpahy (like dm-crypt) also has drawbacks with respect to security/cryptography! See crypttab(5).

dm-crypt's /etc/crypttab:

#<target name>    <source device>            <key file>  <options>
var  UUID=01234567-89ab-cdef-0123-456789abcdef  none  luks,discard



# /etc/fstab: static file system information.
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
### SSD: discard,noatime
### match battery operation default for commit JOURNAL_COMMIT_TIME_AC in Add files in /etc/pm/config.d/*
/dev/mapper/goofy-root /               ext4    discard,noatime,commit=600,errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=709cbe4a-80c1-46cb-8bb1-dbce3059d1f7 /boot           ext4    discard,noatime,commit=600,defaults        0       2
### SSD: discard
/dev/mapper/goofy-swap none            swap    sw,discard              0       0
/dev/mapper/goofy-chroot /srv/chroot         btrfs    ssd,discard,noatime 0       2
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0


# This section allows you to configure which block devices should
# be used by the LVM system.
devices {
    # Issue discards to a logical volumes's underlying physical volume(s) when
    # the logical volume is no longer using the physical volumes' space (e.g.
    # lvremove, lvreduce, etc).  Discards inform the storage that a region is
    # no longer in use.  Storage that supports discards advertise the protocol
    # specific way discards should be issued by the kernel (TRIM, UNMAP, or
    # WRITE SAME with UNMAP bit set).  Not all storage will support or benefit
    # from discards but SSDs and thinly provisioned LUNs generally do.  If set
    # to 1, discards will only be issued if both the storage and kernel provide
    # support.
    # 1 enables; 0 disables.
    #issue_discards = 0
    issue_discards = 1

Smaller system with SSD