2012-05-21. SSD (solid state disks): fast ... reliable? - Problems/limitations. - Suitable options for lifetime and performance. - Monitoring? -------- Background details Each part of the SSD has a limited lifetime of writes/changes, and the nature of pages/blocks/erase/write is such that there are more and less efficient ways of making changes: http://en.wikipedia.org/wiki/TRIM "SSDs store data in flash memory cells that are grouped into pages, with the pages (typically 4 kB each) grouped together into blocks (typically 128 pages per block, totaling 512 kB).[6][10] NAND flash memory cells can only be directly written to when they are empty. If they are considered to contain data, the contents first need to be erased before a write operation can be performed reliably. In SSDs, a write operation can be done on the page-level, but due to hardware limitations, erase commands always affect entire blocks." The TRIM command helps reduce some of the writing when a block is erased, by marking the blocks whose content is unused by the filesystem and therefore need not be copied off the block prior to erasing. It seems a bad idea to use SSDs for at all write-intensive tasks! http://devblog.seomoz.org/2012/05/ssd-drive-failures/ "... we were using SSD drives in a heavily read/write environment to be super-fast harddrives and many of them failed all at once." though a commenter points out that certain SSDs from "Crucial" had a firmware bug that messed them up after 5200h! http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ "The longevity issue comes into play when you consider that SSDs have a limited number of write/erase cycles per cell (1,000-100,000 per cell depending on the media). This is mitigated somewhat by wear leveling which is an automatic use of the least-used cells on a drive to avoid uneven wear, but write amplification limits how much wear leveling can take place. Wear leveling also leads to some write amplification on its own (due to needing to move data which is not changing under certain scenarios)." -------- OS support. Wear-levelling is done in the SSD; shouldn't need support. OS can avoid unnecessary writes: e.g. don't update access times, don't swap often. Filesystem driver (and layers between this and the disk) can issue TRIM to prevent certain extra write-operations (supported in Linux or m$windos since about 2008, Mac partially in 2011; BUT note that Linux distros might not bother turning on suitable options...) May also help to be careful about the position of starts of partitions, to match fs and disk blocks to each other. -------- Monitoring Smartmontools ( http://gsmartcontrol.berlios.de/home/index.php/en/Home ) We have a Media_Wearout_Indicator attribute in SMART monitoring data. e.g. smartctl -a /dev/sda | grep Media_Wearout The attribute Available_Reservd_Space (noticed on an SSD) is probably also relevant (extra blocks for replacing dead ones). These two SMART attributes are confirmed on http://blog.samat.org/2011/05/09/Monitoring-Intel-SSD-Lifetime-with-S.M.A.R.T. -------- Linux-oriented configuration. If using swap on SSD, at least encourage system to avoid it as much as possible. http://en.wikipedia.org/wiki/Swappiness Check (or temporarily set) swappiness by cat /proc/sys/vm/swappiness (or e.g. echo 10 >/proc/sys/vm/swappiness ) Or set permanently in /etc/sysctl.conf vm.swappiness = 2 For ext4 filesystems, use these options noatime,nodiratime,discard ( http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm ) From man mount the "discard" option tells the ext4 driver to send "trim" instructions to the SSD, to let it know which blocks are freed. The other (atime) options are simply to avoid updating metadata just because of file-reads. According to http://en.gentoo-wiki.com/wiki/Solid_State_Disk btrfs and xfs already check for SSD and issue trim automatically, since a year or more ago. But if the filesystem driver is separated from the SSD by e.g. an encryption or RAID layer, the trim in many cases won't work -- e.g. linux dmraid [part of device mapper] DOES support passing trims, but many other raids including linux mdraid (the older one) as well as encryption don't currently pass the trim ( http://en.wikipedia.org/wiki/TRIM ). From ( http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ ), ext4 supports online trim, but ext2/3 only offline (read-only). Prior to setting up the system, make partitions start on 1MB boundaries ( also http://apcmag.com/how-to-maximise-ssd-performance-with-linux.htm ). E.g., make partitions with fdisk -cu and choose 2048 (*512KB) or a multiple thereof for start of partition. (It seems this is to allow for various possible SSD and filesystem block-sizes.) More information about SSDs and optimisation (Gentoo) http://en.gentoo-wiki.com/wiki/Solid_State_Disk E.g. have building happening within tmpfs, if RAM sufficiently big; and put some things from /var into non-ssd, if really wanting to optimise! Using the normal scheduler (CFQ) is recommended for most SSDs other than some Intels (optimised for different r/w from most other SSDs, and possibly better used with NOOP scheduler). --------