Launchpad Entry: appselection-foundations-n-btrfs-support
Created: 3 May 2010
Btrfs is the latest new and sexy Linux filesystem. Lots of bits of userspace need updates to handle it.
See foundations-lucid-btrfs-support for previous discussion.
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.
btrfs has enough interesting features that people already want to start experimenting with it. Right now, you can't even use it as your root filesystem and boot. Enabling this would let us investigate its performance and reliability properties in more detail.
The basic plan here is to enable btrfs as an experimental filesystem to allow development of the tools we expect to be required for 12.04 LTS. The absolute minimum for 10.10 is to fix GRUB so that btrfs can be used as / with a separate ext /boot; everything else is cream.
If things turn out better than expected, we are not opposed to switching to btrfs by default earlier than that. We will evaluate that over the course of this development cycle.
The first priority for GRUB is to permit btrfs on / with a /boot that GRUB can understand (e.g. ext3). This breaks at the moment because btrfs always returns a virtual device major/minor pair in the st_dev member of struct stat.
A patch adding btrfs filesystem handling to GRUB Legacy was posted to the grub-devel list a little while ago. It looks like it should be possible to coerce this into use with GRUB 2, although there may be a GPLv2/v3 compatibility question in which case we will have to clean-room it. Initial iterations are unlikely to support multiple devices, compression, or encryption. The next step after initial single-device support should probably be adding compression support; subvolumes are also important, but may require more design work in GRUB.
Joey has already committed a skeleton partman-btrfs upstream; it just needs to be cleaned up and synced. If this happens before full btrfs handling in GRUB 2, we need to forbid /boot on btrfs.
The release upgrader (and possibly also normal updates) would benefit from being able to take a snapshot of filesystem state at the start of the upgrade. It could then provide a GRUB menu entry to boot back into the old release, provide UI options to commit or discard the snapshot, and automatically revert to the snapshot on errors unless the user opts out for debugging purposes. Michael Vogt will look into this.
ureadahead has the same st_dev problem as GRUB, and can probably use a similar fix. (mountall apparently already does the right thing, though in a different context, using libudev.)
We do not expect to migrate anyone to btrfs automatically, although it's worth noting that converting from ext3/ext4 is relatively straightforward.
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.
This need not be added or completed until the specification is nearing beta.
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.