Ubuntu Wiki

• Launchpad Entry: KarmicSSD

• Created:

• Contributors:

• Packages affected:

Summary

Karmic should fully embrace Solid State Disk (SSD) storage in two ways: to ensure the SSD flash wear is minimised and to maximise SSD I/O performance.

This can be achieved by:

• Using the most appropriate log structured file system.
• Tuning the file system appropriately during installation.
• Using the appropriate mount options.
• Ensuring partitions are aligned appropriately on flash block boundaries.
• If possible, using the ATA TRIM command to free unwanted blocks efficiently on the SSD.
• Use copy-on-write filesystems, such as btfs.
• Use the noop I/O scheduler.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

<Not yet complete>

Rationale

SSD storage is becoming more common on laptops and netbooks as cost reduces and capacity increases. SSD offers benefits in increased I/O performance (for example reduced read/write/seek times) hence quicker boot times, however, filesystem and tuning choices are required to reduce flash wear over extended periods of use.

The ATA TRIM command will soon be supported in newer SSDs and if kernel permits, should be used to reduce wear and increase performance when deleting blocks.

User stories

* Anna has a laptop with an SSD and would like the SSD to last as long as possible without the filesystem wearing the flash out prematurely.

* Bob has upgraded his laptop with an SSD to improve boot performance and would like to squeeze as much speed out of the device as possible.

* Chris now has a new generation SSD that supports the ATA TRIM command and would like this to be supported in Ubuntu.

Assumptions

2.6.30 will support the ATA TRIM command at the lower device level. SSD devices will be ATA TRIM enabled by 9.10 for testing.

Implementation: Use Appropriate Log Structured File Systems

Linux provides several log structure file systems, namely:

While it is up to the user to choice the appropriate file system for their work load, it would be helpful if the user could be recommended log based (journalling) file systems that are appropriate for the SSD.

The main issue is which file system is most appropriate. At present there is a choice from:

ext4, reiserfs, jfs, xfs, btfs to name a few.

Requires some benchmarking to determine which is the winner in terms of speed vs flash wear.

btfs has copy-on-write capability, which should show some form of performance improvement and reduce flash wear. Will it be stable for Karmic?

Implementation: Tune filesystems

• Mount with noatime to reduce unnecessary writes - risky for maildir mailboxes or mount without noatime and use chattr +A on directories where noatime won't cause a problem
• Mount without a journal - reduces 4-12% write (hence wear?) overhead, maybe not worth while.
• Create partitions with expert mode of fdisk to align partitions to be flash optimal - e.g. 128K alignment - installation only. May not gain much performance and adds more installer complexity.
• Use the noop scheduler. The default elevator I/O scheduler is tuned so that platter reads and writes are done in an ordered matter, which is sub-optimal for SSD. Apparently the noop scheduler improves random I/O (untested).

Code Changes

• Ubiquity, on fdisk and mount

Migration

• ATA TRIM support can be used with zero migration issues.
• Selecting the appropriate file system will require either upgrading from ext2,ext3 to ext4 or a complete backup/restore.
• Aligning partitions to optimal flash block boundaries requires a complete re-install - migration not possible
• Selecting appropriate mount options (noatime, etc) is possible as a migration step.

Test/Demo Plan

• Testing comes in two stages:
• Does this actually improve performance - need to test approach on several different SSDs
• Have we broken the installer? - Make sure optimisations don't break current functionality
• Other?

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec