OptimizingSSDInstallations

Summary

This is a proposal to better optimize UNR for netbooks that use SSD as their primary media, both to account for rewrite concerns and slow write performance. There are two parts to this; the first is in ubiquity changes for UNR, so that when SSD media is detected at installation, ext4 is used without data journaling and no swap partition is created when a default partitioning scheme is selected. Tuning for installation on SSD media may also involve aligning partitions to flash block boundries. Similarly, the initial /etc/fstab will mount /tmp and /var/tmp to tmpfs (and possibly /var/log also) and mount options for noatime should be used. The I/O schedular should be changed to noop, and this maybe would be done through grub. Finally, a new package, ssd-optimize, will be created which has SSD-friendly defaults in /etc/sysctl.d and establish new grub options.

Release Note

To address better address the needs of Netbook users who have opted for SSD media, Lucid now includes SSD media specific optimizations which can be enabled from installation.

Rationale

There are several issues common in SSD media as used in low cost Netbooks (or even external USB flash devices used for persistent live images or SD-RAM modules used for root filesystems on some specialized boards) today. The most common is concern about rewrite longevity. Another issue is that write performance can be exceedingly poor. Both of these suggest that, especially in the Ubuntu Netbook Edition, we need to take better care of optimizing for SSD devices, especially given cheap SSD media with these limitations has become common in this hardware profile. Indeed, ARM smartbooks may tend to create further preferences for SSD for better power performance as well. In the long-run SSD media used in low cost netbooks may improve, but these issues exist for the immediate future.

User stories

User installs a new UNE release in ubiquity, selecting a default partition scheme and use "whole" disk. A checkbox will exist for SSD optimizations, and will be selected by default if SSD media is detected. Selecting default partitioning will instruct d-i to produce an install image partition aligned, tuned with ext4 without data journaling, and no swap partition. Grub will be given an extra option to set scheduler=0. /etc/fstab will include tmpfs mount points for /tmp and /var/log. The SSD-optimize package will be installed, and it will include a startup script that does a mkdir /var/log/apt for normal apt functioning, as well as to tune additional system parameters at boot time.

Assumptions

Systems will run OK without swap. OLPC had problems running without swap, because dynamic linking and libc tended to dirty lots of pages, and then those pages had to sit in main memory forever, making memory pressure. This tended to push read-only code pages out of memory (because they could be re-read from the filesystem), which caused excessive paging and visibly slow performance. Make sure that Prelink is used on any system with no swap area, and consider making a small swap area that will let dirty pages from idle daemons and programs be paged out, while still doing small numbers of writes to SSD. This may give acceptable performance on mobile devices with limited DRAM.

Design

Different SSD media have different characteristics. This blueprint targets low cost netbooks, which may often use low cost SSD/flash media. It is thought we can auto-detect SSD media, but we cannot be certain if a given device represents SSD media with the above characteristics or those that do not. Given this, it seems the safest option would be to have a whitelist of vendor identifiers that the OEM team can prepare for netbooks which can make use of auto-detection and a special checkbox which can also be manually set when selecting SSD media for installation. This blueprint also implies some changes to the Debian Installer backend to lay out aligned partitions and to use tune2fs for SSD specific issues. This could also be represented in a new command-line option that can be passed to ubiquity.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Ubiquity would have a new check box for allowing manual override of SSD media detection.

Code Changes

Ubiquity would pass new options to d-i backend if it assumes user is installing ssd media. The d-i backend would handle actually performing specific operations.

Migration

This involves new installs only. No effort is made to migrate a non-ssd install to a SSD optimized one.

Test/Demo Plan

We could benchmark a non-SSD default UNE install to a SSD optimized one. First, to see how much a difference it makes in overall boot time to UNE desktop, and also perform selective I/O benchmarks. It is assumed SSD optimization may somewhat further improve boot time and overall improve general user experience where it is disk bound.

Unresolved issues

Should this blueprint apply to installs onto flash/USB media, which has similar issues, as well? With respect to desktop, it is for the moment assumed some of the optimizations would not be desirable and others not applicable if high-end SSD media is used.

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

Specs/OptimizingSSDInstallations (last edited 2009-11-30 18:41:23 by pool-72-75-154-242)