In future, fdisk will arrange partitions in such a way that the new hard disks with 4-KByte sectors can achieve optimum performance – although, for now, users will still need to select fdisk's appropriate mode of operation manually. The developers of Realtime Linux have released new kernel versions, and the completion of 2.6.32.9 and 2.6.33 is also approaching.

Red Hat developer Karel Zak has released version 2.17.1 of the util-linux-ng tool collection used in many Linux distributions. It includes the "fdisk" command line program which, in its sector-based mode of operation, activated via the "-u" option, will from now on try to align partitions along megabyte boundaries in the same way as Windows 7 and Vista have done for some time. While this sounds like a minor change, it is essential for the gradually emerging large hard disks that work with 4-KByte sectors internally while, for compatibility reasons, externally pretending to use 512-Byte sectors like any other desktop hard disk released in the past 20 years.

Linux file systems prefer to read and write in 4-KByte blocks, but older versions of fdisk arrange the first partition in such a way that it begins with the (512-Byte) sector 63 by default – which is right in the middle of a physical (4-KByte) sector. Writing 4 KBytes of data to the beginning of the partition consequently requires the hard disk to read two physical sectors of 4 KBytes, distribute the 4 KBytes of data across these two physical sectors, wait for the disks to do an extra round and then write the two sectors back to disk.

This causes the data throughput of all 4-KByte sectored hard disks (as well as some RAID arrays) to be significantly lower than that of a volume whose partitions start at (512-Byte) sector numbers which are divisible by eight. More background information can be found in an article at LWN.net. Western Digital's WD10EARS, for example, is one of the first desktop SATA hard disks on the shelves that uses 4-KByte sectors internally.

Only recently, the problem sparked prolonged discussions at Slashdot following the release of an article entitled "Linux not fully prepared for 4096-Byte sector hard drives" by OSNews. The correctness of this headline varies with the interpretation of the term "Linux", as the Linux kernel is hardly at fault; it has already informed userland applications about the parameters relevant for optimum partition alignment since the I/O topology patches in Linux 2.6.31.

Fdisk, on the other hand, has only used this information since the January version of util-linux-ng. However, this doesn't fully eradicate the problem because fdisk isn't the only partitioning tool included in Linux distributions. The distribution installers also need to be adapted or need to use fdisk in the correct way – in a comment concerning the OSNews article mentioned above, the developer of the I/O topology patches, Martin K. Petersen, suspects that this is currently only the case in Fedora.

The version of fdisk used in the current util-linux-ng 2.17.1 not only aligns partitions along megabyte boundaries, it also recognises the "-c" parameter. This parameter disables a DOS compatibility mode which is incompatible with the new approach because it involves aligning partitions along logical cylinder boundaries – this was required by DOS before the advent of LBA addressing and is still used by fdisk unless the tool is switched to sector-based operation by adding "u" or the "-u" command line parameter. While the DOS mode has been marked as deprecated, this version is the last to include it as its default for compatibility reasons. Until this changes, the sector-based display should be activated manually to ensure that 4-KByte hard disks are aligned correctly.

Linux version status

A week after the release of the previous regular Kernel Log, the maintainers of the Stable Series have released kernel version 2.6.32.8, which differs from its predecessor by more than 70 patches. Kernel developer Greg Kroah-Hartman released Linux kernel version 2.6.32.9 just 24 hours ago.

The eighth release candidate of 2.6.33 is now more than 10 days old. Although, in this phase of the development cycle, Torvalds usually releases a new RC every week, we dare not predict whether this indicates the imminent release of Linux 2.6.33, or whether a 2.6.33-rc9 will be appear beforehand.

The past few days have also seen a lot of activity from the developers of the RT branch, who develop Linux kernels with real-time functionality. For instance, an announcement posted by the OSADL (Open Source Automation Development Lab) says the recently released version 2.6.31.12-rt21 is now considered the "Latest Stable". The OSADL web page also offers a short report about the renamed spinlocks mentioned in part 4 of the Kernel Log's "Coming in 2.6.33" mini series. Thomas Gleixner writes that the renaming measure has significantly reduced the size of the real-time patches, in the release email for Linux 2.6.33-rc8-rt1 – the first RT kernel to be based on the current release candidates of Linux 2.6.33.

In brief

Kernel

In mid February, the developers had a long discussion on the LKML about switching the kernel archives at kernel.org to the "XZ" compression format. While no summary or appropriate road map has so far been released, there is evidence to suggest that the kernel sources will also become available in XZ format. XZ compresses more efficiently than Gzip (.gz) and is faster than Bzip2 (.bz2). In the long term the latter may be abandoned and the old files removed; however, files compressed with Gzip will probably remain available.

In his "XFS status update for January 2010", Christoph Hellwig gives an overview of the latest developments in the XFS filesystem area.

Kernel environment ("plumbing layer") and userland drivers

Graphics

See also:

Older Kernel Logs can be found in the archives or by using the search function at The H Open Source. New editions of Kernel Logs are also mentioned on Identi.ca and Twitter via "@kernellog2". The Kernel Log author also posts updates about various topics on Identi.ca and Twitter via "@kernellogauthor".

(thl)

(crve)