Launchpad Entry: kernel-karmic-ssd
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.
AIM: Maximise benefits of fast speed of SSD, and reduce wear.
This can be achieved by:
- Using the most appropriate file system, such as ext4.
- 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 the noop I/O scheduler.
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>
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.
- 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.
- 2.6.31 will support the ATA TRIM command at the lower device level.
- SSD devices will be ATA TRIM enabled by 9.10 for testing.
- SSD devices can be detected either bit a ATA Spin bit being set to zero or, checking for SSD model in /sys/block/sd*/device/model against a whitelist (SSDs usually have an model string that contains SSD).
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. Note that btfs has copy-on-write capability, which should show some form of performance improvement and reduce flash wear. Will it be stable for Karmic?
Requires some benchmarking to determine which is the winner in terms of speed vs flash wear, however ext4 seems to be a good choice, and will be default for Karmic. Benchmarking needs to be done against some typical usecases:
- Mail users. Walking a large inbox and writing to the directory is bad for SSDs.
- Mozilla is known to rewrite data within existing file blocks - also bad for SSDs.
- Building applications - a developer use case.
- Streaming reads and writes, large file downloads and media streaming use cases.
- Office applications, benchmark tunes SSD start up time.
Implementation: Tune filesystems
- 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.
- Alignment must be in powers of 2 block aligment.
128K alignment suggested by SanDisk
- 4MB alignment has been used with some improvement (10-15% improvement from empirical results)
- 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
- Further testing has shown noop scheduler may provide some extra performance.
- Needs further tests on different usecases to be 100% sure.
- 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.
- Mount with tweaked commit intervals, such as commit=120
- Partition Alignment at 128K for Karmic with current SSD technology
- Request the option for alignment size from the installer
- More testing required with partition alignment across broad range of use cases
- Create a WIKI page with recommended tunables for specific SSDs
- Ubiquity, on fdisk and mount
- ATA TRIM support will appear automatically in the kernel - no other changes required.
- 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
- 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
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.