See also: last week's Kernel page.

Kernel development

Unfortunately, 2.3.99-pre4 also contained a "brown paper bag" problem in the filesystem code which caused it to crash on boot. Most users tend to dislike that sort of behavior, even in a development kernel, so 2.3.99-pre5 was rolled out within a few hours. Along with the filesystem fix, pre5 contained a bunch of changes to the code that handles routing of PCI interrupts.

There is a 2.3.99-pre6 prepatch out there; it contains SMP and IO APIC tweaks, and large updates to the I2O subsystem and a number of sound drivers.

The current stable kernel release is still 2.2.14. Alan Cox has evidently sent a final version of 2.2.15 to Linus, but the official kernel had not been released as of this writing.

Dealing with bad blocks. The ext2 filesystem does not currently deal automatically with bad blocks that develop on a disk. It does maintain a list of such blocks (by making them part of a special file), but it can not add a new block to the list on the fly. A number of people have asked why that is, and whether it might be changed sometime soon.

Coping with bad blocks on the fly is hard. By the time the kernel gets around to trying to write a block, the contextual information (such as what file the block belongs to) may be long gone. So, even in the case of a simple file block, finding the file itself to relocate the block could involve a scan of the entire disk. If the block contains filesystem metadata, the job gets harder, since a fair amount of filesystem structure may need to be changed to move the block.

Much of this work can be done with e2fsck, but that requires the filesystem to be unmounted first. The amount of code involved makes it unlikely that the e2fsck code will move into the kernel, however.

Of course, by the time that a bad block has been detected, it's often too late to save the data it contains. Modern disks contain a feature called SMART, which can, in some cases, detect a failing block before it actually goes bad. When this happens, it would be very nice to be able to cope with the problem quickly, so that the data can be saved.

To this end, Andre Hedrick is frantically hacking away trying to get a SMART implementation ready for possible inclusion into 2.4. It's an uphill battle, but, as he puts it, he hasn't yet reached the "half lethal dose" of two tins of caffeinated Penguin Mints within 24 hours... Andre has set a big goal for himself, and it's not clear that a change of this magnitude to the fundamental disk subsystem can be shown to be sufficiently stable by the time 2.4 comes out.

Some also question whether bad block recovery is worth the effort. In these days of cheap drives, it may be better to just back up a drive with known problems and swap it out. Dealing with a serious disk failure is far more expensive, in terms of downtime and people time both, than a new drive. The best bad block recovery scheme may well be to use RAID and a small stash of spares.

Other patches and updates released this week include:

• Red Hat 6.2 users wanting to play with the ext3 filesystem may want to avail themselves of the ext3 kernel RPMs posted by the folks at Red Hat.

• A small replacement for /proc which makes ps work in embedded systems was posted by Borislav Deianov.

• SGI has released version 0.2 alpha of its Scheduled Transfer Protocol driver for Linux.

• BadRAM was posted by Rick van Rein. This patch makes the kernel deal gracefully with defective memory modules by mapping out the parts that do not work.

• Ksymoops 2.3.5 has been released by Keith Owens.

• Ulrich Windl has released PPSkit 0.9.2.

• A snapshot of Real-time Linux 3 has been made available.

• Version 1.0.6 of the Linux USB Guide has been announced by Brad Hards.

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