What's new in SUSE Linux Enterprise 11 SP2
In addition to swapping the kernel for a much newer version, the second major update adds Btrfs support and container virtualisation, features currently absent from other distributions.
Just under three years after releasing SUSE Linux Enterprise 11, SUSE has released the second major revision to the enterprise-oriented Linux distribution. Like the first major update in May 2010, Service Pack 2 includes a range of new features, including a switch from the 2.6.32 Linux kernel to version 3.0, and support for Btrfs and container virtualisation.
From Service Pack 2, SUSE supports the use of Btrfs under the terms of its standard support contract. SUSE introduced the filesystem, which is still marked as experimental in the Linux kernel, in Service Pack 1, where it was classed as an unsupported technology preview. The wording in the release notes implies that Btrfs is only supported for use as the root filesystem, but in response to our enquiries, SUSE explained that the filesystem is generally supported, but that the main usage scenario for Btrfs is as a root filesystem (rather than for data partitions). For disks intended to store large volumes of data, SUSE continues to recommend XFS.
Where Btrfs is used for the root partition, YaST sets up all necessary components for the Snapper infrastructure, which uses native Btrfs functionality to generate a user-configurable number of snapshots of the complete filesystem. These snapshots mean that modified or deleted files can still be accessed for a certain period after modification or deletion. Using a Snapper module for YaST, users can utilise these snapshots to show differences between previous and current file versions, and to revert and repeat changes. If an administrator accidentally deletes key files, the Snapper module can be used to restore them from the snapshot. It can also be used to roll back updates. Because Btrfs can't be used for boot partitions, Snapper is not, however, able to roll back kernel updates or changes to the boot configuration. A video recorded at the BrainShare 2011 conference illustrates its use in practice (from 2:49 minutes).
SUSE does not support the Btrfs functionality for combining multiple disks into one RAID. The release notes recommend using Btrfs on RAID arrays built on top of multiple devices (MD) or device mapper (DM). SUSE is planning to add the fsck.btrfs tool within the next few days via the distribution's update repository. According to the release notes, the "long-awaited" program for checking and repairing Btrfs filesystems should have been available from this repository with the release of SP2.
Ext3 remains the default filesystem, though SUSE continues to support Reiserfs 3.6, XFS and, for users with the High Availability Extension, cluster filesystem OCFS2. The ext4 module included with the kernel is read only and is primarily included to enable ext filesystems to be converted into Btrfs. Users who want to write to ext4 filesystems can add an apposite kernel module using the ext4-writeable kernel module package (KMP), which is not covered by SUSE support.
Btrfs development status
Even in the recently released 3.3-rc5 Linux kernel, the Btrfs configuration help text classes the filesystem as "highly experimental". It also warns that the disk format is not yet finalised, though the Btrfs development team has since hinted that they do not plan to make any further changes to filesystem structure which are not backwards compatible.
Distributions such as Fedora, openSUSE and Ubuntu have long offered the option of using the copy-on-write (COW) filesystem during installation. All three have contemplated making Btrfs their default filesystem, but none has yet ventured to actually do so. Fedora had originally planned to take this step in Fedora 16, but then got cold feet; it has since repeated the process with Fedora 17. One of the reasons for its change of heart was the absence of the improved tool for checking and repairing Btrfs filesystems which SUSE is promising to deliver in the very near future. An unofficial version of the tool has been doing the rounds recently, but an official release remains outstanding.
SUSE Linux Enterprise is the first enterprise distribution with a support contract which covers the use of Btrfs. Oracle's development team has stated that the filesystem will soon be officially supported in Oracle Linux. Like SUSE, and indeed many other companies, Red Hat is also involved in working on Btrfs, development of which is headed by Oracle's Chris Mason. RHEL has long featured Btrfs as a technology preview, but Red Hat staff have indicated that this state of affairs is unlikely to change over the next few months, as Btrfs has yet to undergo field testing as the default filesystem in Fedora.
In response to questions on the suitability of Btrfs for everyday use, Matthias Eckermann, who, as Senior Product Manager, is ultimately responsible for SUSE Linux Enterprise, replied,
"SUSE Linux Enterprise supports the highly scalable XFS filesystem since SLES 8 already, as part of the core delivery. Starting from this solid base for our storage strategy, we followed customer and partner demand and decided three years ago to focus the development of new filesystem functionality on Btrfs.
You certainly never do this alone, but sync and align with other players in the Linux filesystem area. And thus it is not a coincidence that in addition to SUSE Linux Enterprise 11 SP2, also Oracle has announced that they would support btrfs in their next Linux release.
More important though is our own ability to qualify btrfs on all of the five architectures supported by SUSE Linux Enterprise – jointly working with the respective partners. The bitfield betrayal is one of the many outcomes of this process.
And we have validated our approach with customers, who appreciate that we start supporting btrfs now, and encourage us to expand Btrfs' use in the future.
Thus I expect that the 'experimental' warning of btrfs might be dropped in one of the next upstream Linux kernel versions."
With Service Pack 2, SUSE adds support for Linux containers (LXC) to the server edition of the distribution. In contrast to virtualisation with KVM or Xen, container virtualisation does not involve emulating a complete system. A container is an isolated area (roughly speaking an enhanced change root/chroot), such that applications running within a container are only able to see processes running within the same container, despite the fact that they ultimately, like all other system processes, run under the host kernel. Where permitted by the administrator, applications running within a container can communicate with software running elsewhere via the network or via shared memory areas.
The management overhead for container-based virtualisation is significantly lower than for virtualisation using KVM or Xen, although the latter, by emulating a complete system, are better isolated. In its release notes, SUSE stresses that containers should not be used as the primary or only security mechanism in areas where a high level of security is required. SUSE offers some tips on using LXC in practice in the document SLES 11 Virtualization with LXC Quickstart. Solaris has been able to perform container virtualisation for nearly ten years. Web hosting companies are also heavy users, though they rarely use the still relatively new LXC on Linux hosts, preferring OpenVZ or the commercial Virtuozzo Containers, itself based on OpenVZ.