See also: last week's Kernel page.

Kernel development

On the development side, 2.3.18ac8 is out. This patch continues to be a (large) collection of bug fixes, as is appropriate given the current feature freeze. Progress is being made toward that ultra-stable 2.4 release.

On the stable side, the patch is up to 2.2.13pre9. As before, the purpose with this patch is to create a tremendously stable 2.2.13, so that some more disruptive changes (like the knfsd fixes) can go into 2.2.14.

The Kernel Hacking HOWTO has been written and released by Paul Rusty Russell. It is intended to be a first-level primer on how to write code that is meant to be part of the Linux kernel. Rusty says: "Please understand that I never wanted to write this document, being grossly underqualified, but I always wanted to read it, and this was the only way. I simply explain best practices, and aim to cover the most common 80% of what you will need to know to start hacking on the kernel." This document, which primarily describes the 2.3 kernel, is a welcome contribution.

Ext3 support is getting closer. Stephen Tweedie's first shot at an ext3 patch has been available from his FTP site for a couple of weeks. The first release only works with the 2.2.2 kernel, and has some known difficulties. A new release (0.0.2) has been promised for "real soon now," and should have 2.2.12 support as well.

Why is journaling useful? The short answer is "so you don't have to wait for fsck after a system crash." The longer answer requires a bit of background. File systems are complicated data structures on the disk. Even simple-seeming operations can cause changes to happen in several places on the disk. For example, adding some data to the end of a file requires, clearly, that the new data be written to disk. It may also require the allocation of a new disk block, and thus updates to the file's block pointers, its inode, the free block list, and perhaps to the disk quota database as well.

In a well-debugged filesystem, all this activity happens without the user knowing about it. When said user also demonstrates his ignorance of the location of the power cord and brings the whole system down, though, problems can arise. If the new block has been allocated, but the file's block pointers have not been updated, the disk block falls on the floor forevermore. If the change to the free list did not get written, the block could get allocated mistakenly to a second file later on. Essentially, unless all of the changes required for an operation have been written to disk, a crash will leave an inconsistent mess.

The classic Unix answer to this problem is a friendly little program called fsck. Fsck's job is to go digging through the filesystem, find any sort of data structure inconsistencies, and try, somehow, to fix them all up. Linux fsck does a pretty good job of this, but (1) it's no fun watching all those scary messages go by, and (2) it takes a very long time, as anybody who has ever had to fsck a large RAID volume can attest. Thus, even assuming that fsck can fix everything perfectly, it would be nicer to avoid the need to do so.

Journaling can eliminate that need. With journaling, an area of the disk (the "journal file") is set aside for the filesystem's use. When a change is made to the filesystem, every change to be made is written to the journal file and committed to disk; thereafter, a special "commit record" goes in to mark that everything has been written. Only once the change has been fully committed to the journal file is the regular filesystem structure touched.

Now, if the user confuses the floppy "eject" button and the power switch, recovery is easy. Every operation which appears in the journal file with a commit record is copied into the filesystem structure itself. All the rest are simply dropped. The integrity of the filesystem is guaranteed to be preserved, and no fsck is necessary. The system is up and running quickly.

Stephen's journaling patches have been done in a very clever way. The regular ext2 filesystem structure has not been changed at all - under normal conditions, an ext3 filesystem can be mounted as ext2 with no problems. The journal file is exactly that - just another file in the filesystem. Thus there is no need for conversion utilities, no need to worry about going back to ext2 if ext3 does not work out. It is a well-done piece of work that will be a much-appreciated addition to Linux once it stabilizes.

The status of the merged PCMCIA drivers in the 2.3 kernel was clarified by David Hinds this week. In short, the recommendation is still to ignore the built-in PCMCIA code and use the standalone package, unless you really want to dig in and fix problems. The 2.3.18 "ac" patches have been fixing a lot of problems, but a lot of work remains to be done.

It is also worth pointing out that there will always - at least for the forseeable future - need to be a separate PCMCIA package. Like many other capabilities in the kernel, PCMCIA needs user-space help. So a package containing the 'cardmgr' daemon will continue to be necessary, even with PCMCIA now in the kernel itself.

Other patches and updates released this week include:

• DIPC 2.0, the Distributed InterProcess Communication package. DIPC lets you do lots of cluster-oriented things easily, including distributed shared memory.

• A bleeding-edge SMP patch was released by Ingo Molnar. It is meant to clean up much of the SMP and interrupt code; Ingo is looking for people to help shake it out.

• Kmsgdump is a handy utility released by Willy Tarreau; its purpose is to recover from kernel crashes and dump out the messages buffer onto a diskette. People trying to track down problems should be pleased with this one.

Section Editor: Jon Corbet

For other kernel news, see: Kernelnotes Kernel traffic Kernel Newsflash

Next: Distributions