Services

Kernel Log: Coming in 2.6.38 (Part 4) - Storage

Thorsten Leemhuis

Expected in March, the forthcoming kernel will contain the new LIO target framework for implementing Storage Area Networks (SANs). Also new are a kernel-side media presence polling feature for disk drives and various Device Mapper optimisations that are relevant for desktop systems.

With RC6 of 2.6.38 issued last Tuesday (22 February) and Torvalds having just released RC7 late on 1 March, the development of kernel version .38 is slowly entering the home stretch. RC7 fixes a flaw in the Btrfs code, recently discussed on the LKML. that could cause recently created files to be empty when copied with current versions of the "cp" coreutils component.

The Kernel Log continues its "Coming in 2.6.38" mini series with a description of the kernel's storage advancements. Part 1 of this mini-series described the changes in the graphics hardware area, while Part 2 covered file systems and Part 3 the kernel's network code; in the coming weeks, further articles will discuss the kernel's architecture and infrastructure code as well as its audio, USB, and video hardware drivers.

Storage Area Network

The developers have added the LIO multi-protocol storage target developed by linux-iscsi.org to the SCSI subsystem. This allows storage devices to be integrated as SCSI targets which other systems can access via iSCSI, Fibre Channel or FCoE (Fibre Channel over Ethernet). This solution for implementing SANs (Storage Area Networks) will soon replace STGT (SCSI Target Framework; kernel configuration option CONFIG_SCSI_TGT), which has been part of the kernel for some time. The developers of SCST (SCSI Target Subsystem for Linux) had also promoted their solution as a replacement, but were unsuccessful. Apart from various technical aspects, the decision was mainly based on the SCSI subsystem maintainer's assessment of which developer community the kernel hackers would find easier to work with in the long run. The decision caused annoyance among various members of the SCST community who consider SCST to be the better solution.

The architecture of 2.6.38 integrates the LIO SCSI target Implementation.
Source: linux-iscsi.org
A short overview of LIO's features can be found in the commit comment. Some background information on the technical differences between the various SCSI target implementations and on the aspects responsible for the decision in favour of LIO can be found in the article "A tale of two SCSI targets" on LWN.net.

Mainly sponsored by Rising Tide Systems, the development of LIO is far from complete. Between RC5 and RC6, for example, the kernel hackers removed LIO's Procfs interface to avoid having to maintain it in the long term. Procfs was integrated accidentally together with LIO, and the developers are considering a Sysfs interface to replace it. Various patches submitted for 2.6.39 to incorporate the TCM_Loop virtual SCSI module have yet to be reviewed. Originally planned to be included in 2.6.38, the module is designed to provide a local SPC-4 SCSI emulation for arbitrary local raw devices. The developers have, for now, also selected the modular LIO's target engine for inclusion in the kernel. The appropriate protocol drivers are to follow in 2.6.39 â for example a driver for iSCSI, FCoE and FC with HBAs by QLogic.

Polling places

Submitted by Tejun Heo, an "in-kernel polling framework" now enables the kernel itself to monitor the presence of removable storage media (such as memory cards or optical media like DVDs) by regularly polling devices. If a storage medium has been exchanged, the kernel informs userland applications such as the desktop environment â therefore, these applications no longer need to poll for media presence themselves, which has caused various problems that are briefly explained in the commit comment.

The in-kernel polling feature also has less overhead and should require less power. Adjustable via Sysfs, the in-kernel polling feature is disabled in the default configuration to avoid disrupting previously existing userland solutions. Further background information can be found in "Reworking disk events handling" on LWN.net.