See also: last week's Kernel page.

Kernel development

Also in 2.3.47: the logical volume manager (LVM) patch has been included, thus satisfying yet another long-time wishlist item. LVM works by putting a new layer between the kernel's block (disk) device interface and the actual physical devices on the system. New logical "devices" can be created using parts of one or more physical devices. Simple applications include combining multiple partitions (or whole drives) into single, larger logical drives.

The real attraction of LVM, however, is that it also allows the size of logical volumes to be changed on the fly. Any system administrator who has been through the "that partition is too small, now what?" problem (i.e. most of them) will appreciate the ability to say "make that one bigger" and have it happen. A whole class of problems thus goes away; instead of having to bring down the system, back up everything, repartition, then restore everything, it is now possible to simply issue an "lvextend" command.

There is one piece missing, however: LVM can change the size of a logical "partition," but it knows nothing about the filesystem resident therein. With the ext2 filesystem, a few options exist for on-the-fly resizing; see this page on the LVM site for more information on ext2 resizing.

Information on LVM in general can be found on the LVM web site. There is, among other things, an LVM HOWTO, but it could use a bit of work, seeing as it is full of phrases like: "If for example the capacity of a LV gets too small and your VG containing this LV is full, you could add another PV to that VG and simply extend the LV afterwards. If you reduce or delete a LV you can use the freed capacity for different LVs in the same VG." As LVM gets more prime-time attention, one can expect some improvements in this area.

Those wanting to play with LVM should note that the version merged into 2.3.47 does not build properly; see this note for information on how to make it work.

The current stable kernel release is still 2.2.14. Prepatch 2.2.15pre8 was released, followed almost immediately by 2.2.15pre9 after a problem turned up in pre8.

Those wanting to play with devfs should heed one simple warning: do not do anything with devfs, including building it into a kernel, until you have (1) read the documentation, and (2) installed devfsd. With many new kernel options, you can configure them into the kernel, then reboot and play with them at your leisure. If devfs is built in, your system comes up with it mounted on /dev whether you are ready for it or not. And that probably means that many of your devices will no longer exist, your fstab file will be wrong, and so on. You may, for example, see the initial fsck fail with one of those chilling "unable to read superblock" messages that are usually the harbinger of a late night with the backup tapes.

The moral: read the documentation and be prepared before you turn on this one. Your editor, of course, did his homework and would never, ever, have ever actually experienced any of the above troubles...

Delays with host name lookups have been reported by a number of users who have tried out the 2.3.4x kernels. As it turns out, a change in the networking code has created this problem, which may well persist into the 2.4 stable kernel release and require configuration changes on a large number of systems. As one might imagine, not everybody is happy with this state of affairs.

The problem that the kernel developers are trying to fix is a problem built into the UDP protocol. A UDP message sent to a non-existent port yields an ICMP error packet in return. However, if the process sending the initial message has since gone away, it is entirely possible that a new process, which got the same port number, will get the error response intended for the first process. The result can be described, charitably, as "confusion." As servers get bigger and busier, this sort of confusion happens more often.

The approach taken by the kernel folks is to simply not deliver ICMP error responses, since there is no way to know if they are intended for the process currently owning the port or not. The source of confusion is removed, and processes doing UDP communications have to be prepared to time out failed conversations anyway. A (more complicated) mechanism has been put in place whereby processes that really want to see error responses can get them.

So why do things break? A number of Linux distributions are shipped with a configuration (in /etc/nsswitch.conf) that tries to look up hostnames (and other things) via the Network Information Service (NIS) and NIS+ as well. NIS lookups involve UDP communications; previously these would fail immediately with an error, now they must time out instead.

Of course, the administrators of these systems should have taken the NIS entries out of nsswitch.conf a long time ago. But it is an easy thing to overlook - everything "just works" with the default configuration. Unless some sort of workaround is found, expect to see this question asked many, many times once people start using 2.4. David Miller has made it clear that the old behavior is not likely to come back. The end result may be better in the long term, but the short-term headaches will not be pleasant.

What would your development project do if somebody gave it $10,000? The Linux-USB project has been trying to figure that out for a few weeks now, since Andover.Net picked it out for one of its "Beanie Awards." The answer, as laid out in this note, seems to be to split the money up into two equal chunks. One will be used to buy USB equipment for developers; the other will be split among those who have made "obvious significant contributions" to the Linux-USB project.

Other patches and updates released this week include:

• The folks at Axis Communications have announced the release of their port of Linux to the Etrax-100 CPU; it's intended for embedded uses. The port includes a couple of interesting things, including a Bluetooth stack for Linux and a Journaling flash filesystem. The Bluetooth work, in particular, is sure to get some attention; if Linux is to do well in mobile situations it will need a solid Bluetooth implementation. Until now, it lacked one altogether, so things are clearly headed in the right direction. (Information on Bluetooth can be found at bluetooth.com).

• RTLinux V2.2 has been released.

• Netfilter 0.90.2 is out, and in need of testers before it gets put into the mainline kernel.

• Version 1.0 if the Linux USB Guide is out.

• Secrm by Martin Mevald is a patch which can insure secure removal of specially-marked files.

• Just because devfs is in the kernel now doesn't mean an end to the regular series of patches; Richard Gooch is now up to version 160.

• Jeff Garzik has released a new version of his RTL8139 driver.

Section Editor: Jonathan Corbet

For other kernel news, see: Kernel traffic Kernel Newsflash Kernel Trap Linux 2.5.x Porting help

Other resources: Kernel Source Reference L-K mailing list FAQ Linux-MM Linux Scalability Effort Kernel Newbies Linux Device Drivers

Next: Distributions