Difference between revisions of "SSD"

From ArchWiki
Jump to: navigation, search
(reordered and added sections)
(Major re-write)
Line 1: Line 1:
=Accumulated info on how to use your SSD drive under linux=
+
=Solid State Drives - Best Practices=
 +
{{Note| Readers are encouraged to contribute to enhance the quality of this article.}}
  
''under construction, not complete, not nice''
+
As most Archers know, Solid State Drives (SSDs) are not PnP devices.  Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance.  This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Arch (Linux in general).
  
So you got yourself one of those precious, blazing fast SSDs and you want to get the most out of it? There are a number of things to worry about, such as alignment, choice of file system, journaling and TRIM.
+
=Pre-Purchase Considerations=
 +
There are several key features to look for prior to purchasing a contemporary SSD.
 +
==Key Features==
 +
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces the loss of performance over time.
 +
*Buying the right size SSD is also key.  It goes without saying that purchasing the right about of capacity is important.  Like all file systems, target <75 % occupancy for all SSD partitions to ensure efficient use by Linux.
  
==Before buying==
+
==On-line Reviews==
Make sure the SSD you buy has a firmware with TRIM support. This is a vital feature that both prolongs your SSDs lifetime and reduces the loss of performance over time to almost nil. I recommend all of what Anand has ever written about SSDs in general before considering to buy one:
+
This section is not meant to be all-inclusive, but does capture some key reviews.
SSD Anthology (history lesson, a bit dated): http://www.anandtech.com/show/2738
+
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]
SSD Relapse (refresher and more up to date: http://www.anandtech.com/show/2829
+
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date]
He also reviewes most of the SSDs so you'll find up-to-date benchmarks on all of them. Brilliant stuff.
+
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]
  
==Setting up a fresh drive with archlinux==
+
=Partitioning and Alignment=
This guide assumes that you want to install archlinux from scratch on your brand new SSD. For different applications (like using them in a RAID, a server or whatever) many things might be different
+
  
===Step 1: Aligning the drives partitions===
+
Proper partition alignment is key for optimal performance and longevity. The community seems to be in agreement on the use of fdisk as the utility of choice for partitioning SSDs (although one can also find guides whose authors advocate using parted). Consensus opinion on the best settings for number of heads and cylinders is tough to find.  There seem to be two different camps on this issue:
Launch the latest archlinux install medium, then go on launching fdisk with fixed head and sector number options. The head and sector options are a safe bet for many drives. Read the links below to find out more about what they do, as some SSDs might require a different setting for maximum performance.
+
  # fdisk -H 32 -S 32 /dev/sda
+
Now create your partitions.
+
  
{{Warning|When creating the first partition, select cylinder number 2 as the first cylinder, not 1. This ensures that your first partition doesn't get shifted.}}
+
Ted Tso and others recommend using [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 244/56] option:
  
You might not want to create a swap partition if you don't really need it.
+
# fdisk -H 224 -S 56 /dev/sdX
==== Background info ====
+
aligning the SSD to block boundaries:
+
http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment&p=373226&viewfull=1#post373226
+
aligning the SSD to block boundaries when using LVM:
+
http://es.linuxfoundation.org/news-media/blogs/browse/2009/02/aligning-filesystems-ssd%E2%80%99s-erase-block-size
+
  
===Step 2: Choosing a file system===
+
While others advocate the [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32/32] option:
There's lots of talk about what to use. Some say ext2 should be used because it doesn't have journaling, some say ext4 without journaling is best, and some use btrfs. Since TRIM support, journaling can be enabled without much of a drawback as stated by the guy in the link below. If you disable journaling, you end up with a slightly faster system, but in case of a power failure your data might end up garbled. I decided to go with a regular journaled ext4 because it's a laptop and a low battery could garble me some data. If you plan on using a RAID, there's even more to consider, such as stripe-widths and so on.
+
  
  # mkfs.ext4 /dev/sda1
+
  # fdisk -H 32 -S 32 /dev/sdX
 +
==Additional Links on Alignment==
 +
*[http://www.ocztechnologyforum.com/forum/showthread.php?54379-Linux-Tips-tweaks-and-alignment&p=373226&viewfull=1#post373226 Aligning the SSD to block boundaries when using LVM]
 +
*[http://es.linuxfoundation.org/news-media/blogs/browse/2009/02/aligning-filesystems-ssd%E2%80%99s-erase-block-size Another blog entry by Ted Tso]
  
Next, consider which mount flags to use in the entries for your partitions in [[fstab|/etc/fstab]] (see the reasons in the link below):
+
=File Systems=
 +
Many options exist for file systems including ext2, ext3, ext4, XFS, and btrfs.  Initially, ext2 was thought to be a good choice as it lacks journaling which would avoid extraneous read/write cycles.  Ext4 can also be used without a journal and is thought to be superior to ext2 in a number of areas.  The obvious drawback of using a non-journaling file system is data loss as a result of an ungraceful dismount (i.e. post power failure).  With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles.
 +
 
 +
--Placeholder for key data from aforementioned article--
 +
 
 +
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel.  Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4.  It should be noted that at the time this article was written (27-June-2010), a stable version of btrfs does not exist.  See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs.
 +
 
 +
=Mount Flags in /etc/fstab=
 +
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.
 +
 
 +
*noatime - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.
 +
*discard - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33.
  
 
  /dev/sda1 / ext4 defaults,noatime,discard 0 1
 
  /dev/sda1 / ext4 defaults,noatime,discard 0 1
  
{{Note|Omitting the discard option will leave the partition ignoring the TRIM command!}}
+
{{Warning| Users need to be certain that kernel version >=2.6.33 is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag.  Data loss can occur!}}
  
====Background info====
+
=I/O Scheduler=
*btrfs on an SSD on arch: [http://www.madeo.co.uk/?p=346 Intel X25-M Gen2 on linux – migrating to btrfs on kernel 2.6.33]
+
*Thoughts on why journaling isn't much of a deal: [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/ SSD’s, Journaling, and noatime/relatime ]
+
  
===Other SSD Tweaks to Consider===
+
Consider switching from the cfq scheduler to the noop or deadline scheduler.  Using the noop scheduler for example simplifies requests in the order they are received, without giving any consideration to where the data physically resides on the disk.  This option is thought to be advantageous SSDs since seek times are identical for all sectors on the SSD.  For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux-mag article.
==== RAID LVM Usage ====
+
Place holder for this section.
+
==== SWAP Space on and SSD ====
+
If you decided to use a swap partition or file, it's recommended to reduce the "swapiness" of the system to avoid writes to swap. Add this to rc.local:
+
# echo 1 > /proc/sys/vm/swapiness
+
==== I/O Scheduler Change for SSD ====
+
Consider switching from the cfq scheduler to the noop or deadline scheduler.  Using the noop scheduler for example simplifies requests in the order they are received, without giving any consideration to where the data physically resides on the disk.  This option is thought to be advantageous SSDs since seek times are identical for all sectors on the disk.
+
  
To see which scheduler your system is using, view the contents of /sys/block/sda/queue/scheduler:
+
The cfq scheduler is enabled by default on Arch.  Verify this by viewing the contents /sys/block/sda/queue/scheduler:
cat /sys/block/sda/queue/scheduler
+
$ cat /sys/block/sda/queue/scheduler
The scheduler currently in use is listed in brackets:
+
[noop] deadline cfq
[noop] deadline cfq
+
The scheduler currently in use is denoted from the available schedulers by the bracketsTo switch to the noop scheduler, one can add the following line in {{Filename|/etc/rc.local}}:
To force your system to use the noop scheduler by default, add the following line to your /etc/rc.local file:
+
 
  # echo noop > /sys/block/sda/queue/scheduler
 
  # echo noop > /sys/block/sda/queue/scheduler
  
=====Background info=====
+
= Swap Space on SSDs =
More on disk schedulers: http://www.linux-mag.com/id/7564/1/
+
One can place a swap partition on an SSD.  Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all.  The notable exception is systems which make use of the hibernate feature.  The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.
 +
 
 +
# echo 1 > /proc/sys/vm/swapiness
 +
 
 +
Or one can simply modify {{/etc/sysctl.conf}} as recommended in the [http://wiki.archlinux.org/index.php/Maximizing_performance#Swappiness Maximizing Performance] wiki article.
 +
 
 +
vm.swappiness=20
 +
vm.vfs_cache_pressure=50

Revision as of 08:52, 27 June 2010

Solid State Drives - Best Practices

Note: Readers are encouraged to contribute to enhance the quality of this article.

As most Archers know, Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Arch (Linux in general).

Pre-Purchase Considerations

There are several key features to look for prior to purchasing a contemporary SSD.

Key Features

  • Native TRIM support is a vital feature that both prolongs SSD lifetime and reduces the loss of performance over time.
  • Buying the right size SSD is also key. It goes without saying that purchasing the right about of capacity is important. Like all file systems, target <75 % occupancy for all SSD partitions to ensure efficient use by Linux.

On-line Reviews

This section is not meant to be all-inclusive, but does capture some key reviews.

Partitioning and Alignment

Proper partition alignment is key for optimal performance and longevity. The community seems to be in agreement on the use of fdisk as the utility of choice for partitioning SSDs (although one can also find guides whose authors advocate using parted). Consensus opinion on the best settings for number of heads and cylinders is tough to find. There seem to be two different camps on this issue:

Ted Tso and others recommend using 244/56 option:

# fdisk -H 224 -S 56 /dev/sdX

While others advocate the 32/32 option:

# fdisk -H 32 -S 32 /dev/sdX

Additional Links on Alignment

File Systems

Many options exist for file systems including ext2, ext3, ext4, XFS, and btrfs. Initially, ext2 was thought to be a good choice as it lacks journaling which would avoid extraneous read/write cycles. Ext4 can also be used without a journal and is thought to be superior to ext2 in a number of areas. The obvious drawback of using a non-journaling file system is data loss as a result of an ungraceful dismount (i.e. post power failure). With modern SSDs, Ted Tso advocates that journaling can be enabled with minimal extraneous read/write cycles.

--Placeholder for key data from aforementioned article--

Btrfs support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was written (27-June-2010), a stable version of btrfs does not exist. See this blog entry for more on btrfs.

Mount Flags in /etc/fstab

There are several key mount flags to use in one's Template:Filename entries for SSD partitions.

  • noatime - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.
  • discard - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33.
/dev/sda1 / ext4 defaults,noatime,discard 0 1
Warning:
Template error: are you trying to use the = sign? Visit Help:Template#Escape template-breaking characters for workarounds.

I/O Scheduler

Consider switching from the cfq scheduler to the noop or deadline scheduler. Using the noop scheduler for example simplifies requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous SSDs since seek times are identical for all sectors on the SSD. For more on schedulers, see this Linux-mag article.

The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:

$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

The scheduler currently in use is denoted from the available schedulers by the brackets. To switch to the noop scheduler, one can add the following line in Template:Filename:

# echo noop > /sys/block/sda/queue/scheduler

Swap Space on SSDs

One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.

# echo 1 > /proc/sys/vm/swapiness

Or one can simply modify Template:/etc/sysctl.conf as recommended in the Maximizing Performance wiki article.

vm.swappiness=20
vm.vfs_cache_pressure=50