Linux in the news
All in one big page
See also: last week's Kernel page.
The current development kernel release is 2.3.8 (announcement here). This is still a "be sure you have good backups" release. Many of the worst bugs in the new I/O system have been shaken out in this release, but some still remain. This is a release to be careful with.
So what are the massive changes here? Essentially, the filesystem code has been changed to eliminate the use of the buffer cache for write operations. File blocks that had been written to used to be copied first into the buffer cache, then into the page cache, then to disk. Removing the buffer cache step eliminates one copy of the data and reduces memory usage, resulting in faster operations.
Access to the page cache has also been threaded, which can lead to much faster I/O on multiprocessor systems. Finally, the file read code has been optimized somewhat. These are all massive changes, so it's not surprising that some glitches remain. Shaking out the remaining problems may take a little while yet - that is what development kernels are for.
The actual, observed results from these changes seem to be mixed thus far, with some people reporting impressive speedups and others seeing slight slowdowns. Expect the end result, when all is ironed out, to be a big performance win.
It was asked whether this work would be backported to 2.2. The answer seems to be a very strong "no." It's too much of a change to go into the 2.2 series, and the Powers That Be are still claiming that 2.4 will be out sometime in the fall.
The credit for this work goes to Linus Torvalds, Ingo Molnar, and David Miller. See this message from Linus for a bit more information on what was done.
The current stable kernel release remains 2.2.10, unchanged from last week. Alan Cox has released 2.2.10ac3, which contains a substantial set of fixes and updates.
There have been consistent reports of file corruption errors in 2.2.9 and beyond. This is a strange problem - it affects relatively few people, and has proved to be very hard to nail down. It was initially thought to be hardware-related, but enough evidence has come in to strongly indicate the existence of a kernel bug.
Alan Cox is hot on the trail of this problem - see his first and secondsummaries of what he has turned up so far. It may well be that the problem will have been nailed down by the time you read this; if so, information can be found in the LWN daily updates page.
Is khttpd a good idea? Khttpd, as mentioned in previous LWN kernel pages, is a kernel-based web server which is meant to provide high-speed response to queries for static pages. It can answer simple queries, and has the ability to pass off everything else to a user-space process, such as Apache.
There has been a lot of debate over whether khttpd is a good idea or not. Detractors claim that khttpd represents kernel bloat, that it is insufficiently general, and that some userspace servers (phhttpd, for example) can get better performance anyway. Proponents see khttpd as a way to beat Microsoft at the benchmark game, point out that nobody is forced to use it, and dispute the performance claims. Resolution of the debate seems distant, to say the least. Interested people may want to see the comments of Arjan van de Ven (the author of khttpd) on the subject.
The status of IEEE-1394 ("firewire") development. The developers of two competing firewire implementations - Emanuel Pirker and Andreas Bombe - would appear to have resolved their differences. This note from Emanuel describes the way forward: Andreas's code, being generally better, will replace much of the earlier code put out by Emanuel. The best parts of Emanuel's system will be merged in, and firewire development will continue with a single implementation and code base.
The future of Linux architecture and development became a topic of discussion after Eric Raymond posted this noteextolling the virtues of the Erosexperimental operating system. Expressed (over) simply, Eros provides (1) an integrated, persistent object store instead of a filesystem, and (2) a full capability-based model. Eric suggests that Linux developers may want to consider a similar model for the long term.
This suggestion was controversial, to say the least. Prominent kernel developers seem to feel that a lot of the capabilities provided by Eros - garbage collection, persistent object store, etc. - are best provided in user space. Whether you are operating in an object store model or in a more conventional mode, the capabilities needed are about the same: memory allocation and protection. Best to provide only those underlying capabilities and layer the rest in user space.
See also Hans Reiser's posting on how current filesystems are inadequate for the future. He proposes bringing in a number of the capabilities provided by database (and other) systems into the filesystem level.
Patches and updates posted this week include:
Section Editor: Jon Corbet
June 24, 1999