22 February 2012, 15:35

Kernel Log: Coming in 3.3 (Part 2) - Filesystems and storage

by Thorsten Leemhuis

The Btrfs and MD code offers new ways to change RAIDs while keeping data intact. Ext4 filesystems can now be expanded more quickly. The kernel also gained a driver for an upcoming storage device interface.

For Linux 3.3, the kernel developers have made a number of changes and additions to the Btrfs balancing and restriping code, which rearranges data within Btrfs volumes (1, 2, 3, 4, 5, 6); these changes will allow RAIDs created with Btrfs to migrate – for example, from a RAID 1 into a RAID 10. The new code also allows this kind of migration to be paused, cancelled and restarted after a crash.

There are now a few optional Btrfs functions that can be compiled in and used by the still experimental filesystem to conduct integrity checks during operation (1, 2), helping to analyse situations that lead to inconsistent filesystems. The help text for this feature's kernel configuration option warns that it is "dangerous" and should not be used during normal operation.

Current state of development

Development of Linux 3.3, expected in mid-March, continues with the release of the fourth release candidate (RC). After the third RC came with no big surprises, the fourth was a bit late: Torvalds and a few other developers hunted down an error that led to problems such as transmission errors when using WPA2. The problem, now fixed in RC4, only showed up when a 32-bit kernel was running on an x86 processor with AES-NI support, as older kernels there didn't correctly restore the condition of the FPU (floating-point unit) in certain situations.

Expanding

The Ext4 code gained a new mechanism for resizing Ext4 filesystems (for example 1). With this, it is not mainly a user space program but the kernel itself that is primarily concerned with resizing. According to benchmarks a developer ran with an earlier version of the code that was eventually included, the new mechanism needs only 3.5 seconds to resize a 20 GB drive to 230 GB; the approach previously needed more than 5 minutes. However, the new technique does not yet support some of the newer Ext4 features, including Big Allocations (Bigalloc), introduced in Linux 3.2.

Taking out the trash

The XFS developers have removed the "nodelaylog" mount option. This was used to activate an older method of operation for writing log data that the kernel hasn't used by default for some time now. The newer approach, its developers say, fixes a performance problem related to writing metadata. Some background information can be found in the video of the "XFS: Recent and Future Adventures in Filesystem Scalability" presentation held by Red Hat developer Dave Chinner at this year's linux.conf.au; LWN.net summarised the presentation.