KarmicSSD
|
Size: 4153
Comment:
|
Size: 4237
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 26: | Line 26: |
| <Not yet complete> |
|
| Line 43: | Line 45: |
== Design == You can have subsections that better describe specific parts of the issue. |
SSD devices will be ATA TRIM enabled by 9.10 for testing. |
| Line 58: | Line 57: |
| Requires some benchmarking to determine which is the winner in terms of speed vs flash wear. == 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. |
|
| Line 61: | Line 69: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | * Ubiquity, on fdisk and mount |
| Line 72: | Line 80: |
| It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. | Testing comes in two stages: |
| Line 74: | Line 82: |
| This need not be added or completed until the specification is nearing beta. == Unresolved issues == This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. |
* 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? |
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.
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.
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.
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.
KernelTeam/Specs/KarmicSSD (last edited 2009-08-11 20:15:50 by 91)