Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

From wiki:

The vital TRIM function is supported by the Linux OS starting with 2.6.33 kernel (available early 2010). However, support amongst various filesystems is still inconsistent or not present. Proper partition alignment is also not carried out by installation software.

So, which filesystem works best for SSD and supports TRIM + partition alignment during install and is available on Ubuntu?

share|improve this question

migrated from stackoverflow.com Jan 3 '11 at 18:07

This question came from our site for professional and enthusiast programmers.

5 Answers 5

up vote 61 down vote accepted
+50

Filesystem EXT4, EXT4 + TRIM:

  • The first of these is easy to set up and can both improve performance and, more importantly, the longevity of your SSD by reducing unnecessary writes (keeping in mind the memory used in SSDs has limited write-rewrite cycles).

  • By default, many distributions including Ubuntu use the relatime flag for updating file metadata when files are accessed, but you're unlikely to care about last access times. Additionally, Linux supports TRIM with Ext4. TRIM is important for maintaining the performance of an SSD over time as files are added, deleted and changed and lets the SSD know which blocks can be safely cleared. No distributions currently enable it by default, but it's simple to do by adding the discard flag to any mounted SSDs.

  • To make all these changes, open up a terminal and run: sudo nano -w /etc/fstab

  • Then for all SSD devices in your system remove relatime if present and add noatime,discard so it looks something like this: /dev/sda / ext4 noatime,discard,errors=remount-ro 0 1

  • The scheduler helps organise reads and writes in the I/O queue to maximise performance. The default scheduler in the Linux kernel is CFQ (Completely Fair Queuing), which is designed with the rotational latencies of spinning platter drives in mind. So while it works well for standard hard drives, it doesn't work so well when it comes to SSDs.

  • Fortunately, the kernel comes with some other schedulers to play with, and here the deadline and NOOP schedulers are ideal. Both are basic schedulers that guarantee fast turnaround of I/O requests. NOOP is basically no scheduler at all, it's a basic FIFO (First In, First Out) queue whereas deadline does some sorting to guarantee read requests take priority over write, which is useful if you want to guarantee read responsiveness under heavy writes.

  • Changing scheduler is easy, and even better -- you can do it on a per-device basis if you have a mixed SSD and spinning platter hard drive system, using deadline for SSDs and CFQ for traditional drives. As CFQ is the default, change SSDs to use deadline by opening up a terminal and running: sudo nano -w /etc/rc.local.

  • Then add the following line for each SSD in your system: echo deadline >/sys/block/sda/queue/scheduler.

  • Changing sda to sdb and so on for each SSD device. If you only have SSDs in your system, you can instead set the global scheduler policy to apply to all devices at boot time.

  • For Ubuntu and other distributions using GRUB2, edit the /etc/default/grub file and add deadline to the GRUB_CMDLINE_LINUX_DEFAULT line like so: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline.

  • Then run: sudo update-grub2.

Some inputs on the SWAP Partition:

  • Linux is pretty good at only using swap if it really needs to, but even so if you're installing to an SSD and you have a mechanical hard drive in your system, be sure to put the swap partition on it instead of the SSD.

Partition Alignment:

  • Finally there's partition alignment, but this can only be done with a clean system before you install either Linux or Windows. Partition alignment is critical for SSDs as, being memory-based devices, data is written and read in blocks known as pages. When partitions aren't aligned, the block size of filesystem writes isn't aligned to the block size of the SSD, causing extra overhead as data crosses page boundaries.

  • Aligning partitions is simply a matter of ensuring the first partition starts on a clean 1MB boundary from the start of the disk, ensuring whatever block size the filesystem uses will align with the block size of the SSD (which can also vary). If you create partitions using Windows 7 on an empty drive, it will start partitions at the 1MB boundary automatically.

  • In Linux, simply run fdisk -cu (device) on the drive you want to partition, press n for new partition, p for primary and enter a start sector of at least 2,048. The general rule is that the starting sector must be divisible by 512, but to cater for all variations of SSD page size and filesystem block size, 2,048 is a good idea (and equates to 1MB).


So use EXT4 + TRIM with a SWAP on a mechanical hard drive or no SWAP on SSD.

Source : How to Maximize SSD performance

share|improve this answer
    
GPT is the modern method using gdisk & grub 2.0.x, (I guess someone mentioned it below in an answer) and MBR is the legacy method using the old grub 0.9.7 and fdisk.. you can find more here : wiki.archlinux.org/index.php/Solid_State_Drives –  aliasgar Aug 30 '12 at 7:03
4  
Sadly, this nice answer, while being wrong about schedulers, has been entirely (and probably illegally) copied from this website... –  Totor Feb 25 '13 at 22:25
4  
It is unnecessary to specify nodiratime when you also specify noatime. Agreed, it looks cool and advanced to fellow nerds, but since noatime disables atime on inodes, and directories are inodes too, it's like saying "wash your hands, and wash your thumbs too". :) –  Redsandro Jun 23 '13 at 12:23
1  
@Jarl While I agree with you on the respect/copyright issue, keep in mind the StackExchange policy: It is preferred to write down content here instead of referring external resources to avoid dead links and 404s in the future. The source could have been made more obvious though. –  Lukas Jul 3 '13 at 17:11
1  
@Lukas it is nicer to explain here rather than just giving a link to a website where the answer may be found. However this "policy" is not above the law, therefore copyright infringement is not an option. –  Totor Sep 18 '13 at 13:50

Short anwser

  • Choose ext4, and either mount it with the discard option for TRIM support, or use FITRIM (see below). Also use the noatime option if you fear "SSD wear".

  • Don't change your default I/O scheduler (CFQ) on multi-applications servers, as it provides fairness between processes and has automatic SSD support. However, use Deadline on desktops to get better responsiveness under load.

  • To easily guarantee proper data alignment, the starting sector of each partition must be a multiple of 2048 (= 1 MiB). You can use fdisk -cu /dev/sdX to create them. On recent distributions, it will automatically take care of this for you.

  • Think twice before using swap on SSD. It will probably be much faster compared to swap on HDD, but it will also wear the disk faster (which may not be relevant, see below).

Long answer

  • Filesystems:

Ext4 is the most common Linux filesystem (well maintained). It provides good performance with SSD and supports the TRIM (and FITRIM) feature to keep good SSD performance over time (this clears unused memory blocks for quick later write access). NILFS is especially designed for flash memory drives, but does not really perform better than ext4 on benchmarks. Btrfs is still considered experimental (and does not really perform better either).

  • SSD performance & TRIM:

The TRIM feature clears SSD blocks that are not used anymore by the filesystem. This will optimize long-term write performance and is recommended on SSD due to their design. It means that the filesystem must be able to tell the drive about those blocks. The discard option of ext4 will issue such TRIM commands when filesystem blocks are freed. This is online discard.

However, this behavior implies a little performance overhead. Since Linux 2.6.37, you may avoid using discard and choose to do occasional batch discard with FITRIM instead (e.g. from the crontab). The fstrim utility does this (online), as well as the -E discard option of fsck.ext4. You will need "recent" version of these tools however.

  • SSD wear:

You might want to limit writes on your drive as SSD have a limited lifetime in this regard. Don't worry too much however, today's worst 128 GB SSD can support at least 20 GB of written data per day for more than 5 years (1000 write cycles per cell). Better ones (and also bigger ones) can last much longer: you will very probably have replaced it by then.

If you want to use swap on SSD, the kernel will notice a non-rotational disk and will randomize swap usage (kernel level wear levelling): you will then see a SS (Solid State) in the kernel message when swap is enabled:

Adding 2097148k swap on /dev/sda1. Priority:-1 extents:1 across:2097148k SS

  • I/O Schedulers:

Also, I agree with most of aliasgar's answer (even if most of it has been -illegally?- copied from this website), but I must partly disagree on the scheduler part. By default, the deadline scheduler is optimized for rotational disks as it implements the elevator algorithm. So, let's clarify this part.

Long answer on schedulers

On "recent" kernels, SSD disks are automatically detected, and you may verify this with:

cat /sys/block/sda/queue/rotational

You should get 1 for hard disks and 0 for a SSD.

Now, the CFQ scheduler can adapt its behavior based on this information. Since linux 3.1, the kernel documentation cfq-iosched.txt file says:

CFQ has some optimizations for SSDs and if it detects a non-rotational media which can support higher queue depth (multiple requests at in flight at a time), [...].

Also, the Deadline scheduler tries to limit unordered head movements on rotational disks, based on the sector number. Quoting kernel doc deadline-iosched.txt, fifo_batch option description:

Requests are grouped into ``batches'' of a particular data direction (read or write) which are serviced in increasing sector order.

However, tuning this parameter to 1 when using a SSD may be interesting:

This parameter tunes the balance between per-request latency and aggregate throughput. When low latency is the primary concern, smaller is better (where a value of 1 yields first-come first-served behaviour). Increasing fifo_batch generally improves throughput, at the cost of latency variation.

Some benchmarks suggest that there is little difference in performance between the different schedulers. Then, why not recommend fairness? when CFQ is rarely bad in the bench. However, on desktop setups, you will usually experience better responsiveness using Deadline under load, due to its design (probably at a lower throughput cost though).

That said, a better benchmark would try using Deadline with fifo_batch=1.

To use Deadline on SSDs by default, you can create a file, say /etc/udev.d/99-ssd.rules as follows:

# all non-rotational block devices use 'deadline' scheduler
# mostly useful for SSDs on desktops systems
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="deadline"
share|improve this answer

The archlinux article Solid State Drives says in the section Choice of Filesystem :

Many options exist for file systems including Ext2/3/4, Btrfs, etc.

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. Users are encouraged to read the Btrfs article for more info.

Ext4
Ext4 is another filesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detect the disk nature; users must explicitly enable the TRIM command support using the discard mount option in fstab (or with tune2fs -o discard /dev/sdaX).

Both Btrfs and Ext4 fulfill the two major requirements for efficient use of the SSD :

  • The filesystem has to be able to issue ATA_TRIM commands to the underlying SSD
  • The filesystem must not perform unneeded writes to the disk

For performance, there are two other requirements :

  • Partitions need to be aligned to the block size of the SSD
  • TRIM must be explicitly enabled for each Ext4 formatted partition

The first one is nowadays automatic with most Linux installers. fdisk will also create partitions at the 1024KB border if started with the "-cu" flags.

The second is automatic for Btrfs, but for Ext4 this is done manually by adding "discard" to the list of mount options for each Ext4 partition in the "/etc/fstab" file. For more details see this howto.

In my opinion, this required little fiddling with fstab for Ext4 is no reason not to use this mature and excellent filesystem.

share|improve this answer

JFTR, take a look at this comparative:

http://www.mayrhofer.eu.org/ssd-linux-benchmark

Both btrfs and ext4 are more or less at the same level, perhaps ext4 is a little bit better.

share|improve this answer

BTRFS IMO. Ubuntu 8.04 and later have included versions of GRUB that are GPT aware. With GPT and Gdisk it will align your partitions for you. I believe fdisk will do that as well though.

Anyway, here is a link to an Ubuntu install on a BTRFS file system.

http://www.linuxbsdos.com/2011/05/05/how-to-install-ubuntu-11-04-on-a-btrfs-file-system/

Hope that helps.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.