Some Practical Linux SSD drive Techniques
[Notation assumes drive '/dev/sda' is an SSD Flash drive.]
0/ Does your drive support TRIM ? [INFORMATIONAL]
Code:
su -c 'hdparm -I /dev/sda' | grep TRIM
* Data Set Management TRIM supported
* Deterministic read data after TRIM
Asterisk '*' above indicates the feature is present.
[Note: If your SSD drive does not support TRIM, then some Techniques do not apply].
1/ Align File Systems & Partitions. [PERFORMANCE]
Align partitions to at least a multiple of 4KiB (8 - 512B sector) boundaries.
[Note: gparted defaults to 1MiB alignment]
Code:
$ su -c 'gdisk -l /dev/sda'
[...]
Number Start (sector) End (sector) Size Code Name
1 2048 63490047 30.3 GiB 0700 Linux/Windows data
2 63490048 80295935 8.0 GiB 8200 Linux swap
3 80295936 173000703 44.2 GiB 0700 Linux/Windows data
4 173000704 234440703 29.3 GiB 0700
Each start sector above is a multiple of 8, so aligned to 4KiB.
2/ Choose a file system type that supports TRIM. [PERFORMANCE,TRIM-only]
The 3.0 kernel fully supports TRIM for the following file systems, when the 'discard' mount option is used.
btrfs, ext4, (v)fat, gfs2, nilfs2, xfs.
The following file systems can use the 'fstrim' utility to perform a trim of of mounted filesystems.
btrfs, ext3, ext4, ocfs2 and xfs.
SWAP block device will use TRIM automatically, without configuration, if available.
The block manager used by LVM and mdadm (software RAID) support TRIM through to the device. (since 2.6.37 kernel)
3/ Know your filesystem. [WEAR, btrfs optimization]
btrfs has an "ssd" mount option that reduces the rate of mirrored superblock & metadata updates.
4/ File System block size of at least 4KiB should be selected. [PERFORMANCE]
btrfs, ext3, ext4, gfs2, nilfs2, xfs - default is 4KiB block size.
ext3,ext4: blocksize is controlled by /etc/mke2fs.conf.
ocfs2: 4KiB is the minimum.
vfat: see mkfs.vfat options -s and -S.
5/ Never use defragmentation on an SSD drive. [WEAR]
SSD defragmentation generates writes which wear the drive, and does not significantly improve performance.
6/ Never use 'shred' or similar utilities to scrub files. [WEAR]
Utilities such as 'shred' overwrite a file repeatedly. SSDs writes are NOT to the same physical block, so these methods cause wear with no advantage. 'rm' is sufficient.
7/ Eliminate "Elevator" disk scheduler. [PERFORMANCE, RELIABILITY]
Rotating disks use the 'elevator' algorithm to schedule block access. This algorithm makes no sense for a SSD media where there are no cylinders and seek time is nearly constant.
Individual drives can use distinct scheduling algorithms by adding the following line to /etc/rc.d/rc.local
echo noop > /sys/block/sda/queue/scheduler
This causes operations to complete more nearly in-order, which can be an advantage for crash recovery.
8/ Reduce SSD Write Activity. [WEAR]
This is a list of methods to reduce the amount of SSD drive writes and therefore reduce wear and increase drive lifespan. Each method has both PROs and CONs. These techniques are listed roughly in order from least controversial, to most controversial.
8A/ Minimize file and directory access-time writes.
POSIX filesystems record access time (atime) for files. Storing access time means that each read or write a file or directory read operation causes an eventual write operation. These access time writes can be reduced in three distinct ways with the 'relatime', 'nodiratime' and 'noatime' mount options.
i) 'relatime' causes the file system to only update the access time to keep it in the correct relative order, and is mount default for recent Fedora. A few legacy applications like 'mutt' require this. This technique causes a moderate reduction in metadata writes.
ii) 'nodiratime' causes the file system to not update access times for directory entry accesses.
iii) 'noatime' prevents atime writes for both directories and files, and effetively eliminates all atime writes.
PRO: Each method reduces writes and therefore drive wear.
CON: Each method reduces the amount of atime information.
RECOMMENDATION: Unless you use mutt or similar, mounting with 'noatime' is strongly recommended for SSD drives.
--
8B/ Reduce log writes to SSD.
The system logs create numerous continuing log files and these can cause voluminous writes. Alternatives are to reduce the volume of messages, write logs to a rotating drive or to send log messages over the net to another system for recording, or to write logs to a ramdisk.
i) Reduce the volume of log messages.
Accomplished by raising the privilege level of messages logged, for example from 'info' and above, to 'warn' and above in the /etc/rsyslog.conf file. See "man rsyslog.conf" for details.
PRO: reduces log volume
CON: reduces log information content
ii) Write logs to a rotating drive.
An fstab entry similar to ....
/dev/sdb4 /var/log ext4 noatime 0 0
causes the device to be mounted on top of /var/log directory, however this mount will occur after rsyslog has already opened some log files. So after the mount (perhaps in /etc/rc.d/rc.local) it is necessary to send rsyslogd a SIGHUP signal to cause it to close and reopen log files.
/bin/kill -s HUP $(cat /var/run/syslogd.pid)
PRO: completely eliminates log writes to SSD
CON: requires a separate rotating disk
iii) Send logs over the net.
There are three transport protocols supported by current rsyslogd; UDP, TCP and RELP. Configuration is discussed in "man rsyslog.conf". The receiving system firewall and rsyslogd must be configured to accept the log messages.
PRO: completely eliminates log writes to SSD
CON: requires a separate log server
iv) Write logs to a ramdisk
An fstab entry similar to ....
none /var/log tmpfs size=10% 0 0
and a /etc/rc.d/rc.local line similar to
/bin/kill -s HUP $(cat /var/run/syslogd.pid)
allocate a maximum of 10% of dram for use by logs.
PRO: completely eliminates log writes to SSD
CON: uses some DRAM. If dram allocation fills, then the logs will cease. On a crash or reboot, all log message are lost.
COMMENT: Despite the considerable CONs this method is practical.
RECOMMENDATION: Technique 'i' is recommended without reservation and technique 'iv' is suggested as an aggressive approach.
--
8C/ Configure browser to use memory caches.
For firefox, use the URL "about:config" and set
browser.cache.disk.enable false
browser.cache.memory.capacity 65536
or
browser.cache.memory.max_entry_size 65536
Similar for thunderbird and chrome browser.
PRO: No apparent performance deficit.
CON: Uses a small amount of DRAM.
RECOMMENDATION: Unqualified recommendation.
--
8D/ Move /tmp to ramdisk
Add this line to /etc/fstab
none /tmp tmpfs size=10% 0 0
where 10% is the maximum fraction of DRAM available to /tmp.
PRO: All /tmp writes avoid SSD wear.
CON: /tmp may fill, /tmp content, tho' generally unimportant is lost after reboot.
RECOMMENDATION: recommended
--
8E/ Consider journals for ext3, ext4.
WARNING: *** DO NOT run without a journal until you understand the potential hazards.
Journals require considerable additional disk I/O so they cause wear and performance degradation.
File system journals allow for clean(er) crash recovery. The boot after an 'unclean' shutdown your linux system will fsck file systems and attempt to mount and proceed automatically. This is generally successful with journaling in place. Running without a journal makes catastrophic file system failure more probable, though still unlikely.
Two approaches:
i) Eliminate journals altogether (*controversial*)
Some filesystems may be easily reconstructed, making risk acceptable.
To eliminate journalling, do this to a unmounted or read-only ext3/ext4
tune2fs -O ^has_journal /dev/sda1
ii) Reduce the amount of journal writes
Mount each SSD ext3 or ext4 with the "data=writeback" option. This means the ext4 will only journal metadata.
Journaling mode of ext3 and ext4 file systems cannot be changed after mount. So 'regular; file systems like /home can have their journalling mode set in the fstab like...
UUID=308[...]d56 /home ext4 discard,noatime,data=writeback 0 0
But the root '/' is mounted by the inintramfs the parameter MUST be included in the grub.cfg configuration file, like,
linux /boot/vmlinuz- ... elevator=noop rootflags=data=writeback
[WARNING: **** for Linux 3.0 and later kernels, setting the ext3/4 root file system option "data=..." in fstab may prevent the remount and may cause boot failure].
RECOMMENDATION: Method 'ii' is safe and has performance and wear advantages. Method 'i' (journal elimination) should only be used when file system reconstruction is available.
(continued)