The five best things in Linux 2.6.27 by Steven

October 16, 2008 – 12:29 P.M.

The five best things in Linux 2.6.27

Does anyone really know what will be better in Windows 7? I don’t and I follow Windows almost as closely as I do Linux. With Linux, on the other hand, we know exactly what we’re getting well in advance of its arrival. In this latest Linux kernel, I see several outstanding new features that have been coming down the road for some time.

After a brief hardware hiccup with Intel’s e1000e gigabyte Ethernet firmware, Linux 2.6.27 was released on October 9th. It’s a good, but not ground-breaking, kernel. Still, it has at least five significant improvements.

The first of these, in my opinion, is a new way of handling device firmware. In the best of all possible worlds, firmware should be compiled with each driver. Linux users know all too well that, despite the opening of some proprietary driver firmware by vendors like Atheros, the Wi-Fi chip OEM, too many devices still require proprietary firmware. In Linux 2.6.27, the firmware blobs (binary large object) now have a permanent home: the new directory, ‘/lib/firmware.’

This works for Linux in two ways. The first is that it will make it easier for all Linux distributors to handle proprietary drivers in a single common way. For users this translates into making it easier to use this kind of devices. For those users who don’t want a thing to do with proprietary drivers, it also makes it easy for them to make sure that their PCs don’t inadvertently use the closed software.

Number two on my list is that Linux 2.6.27 took another big step in supporting Webcams. The first major step came in the last Linux kernel, 2.6.26, which brought in USB Webcam support. Now, with the addition of the gspca (Generic Software Package for Camera Adapters) driver, new Linux distributions will have baked-in support for Webcams built around the very popular spca5x chip family.

Next up, and in the long-run this will probably be the most important change, Linux now supports direct access to flash-memory based storage devices, such as USB drives and the increasingly popular SSDs (Solid State Drives) . Linux does this with its new UBIFS (unsorted block images file system).

Older operating systems, and not just Linux, treat flash drives as if they were ordinary hard drives. That works but it’s fails to take advantage of SSD’s far faster read and write speeds. In Linux/Unix/Mac terms, ordinary drives are ‘block devices.’ Flash drives are MTDs (Memory Technology Devices). The key difference is that block devices, like your hard drive, divided storage space into relatively small, 512, 1,024, 2,048, etc. bytes. MTDs use ‘eraseblocks’ instead of sectors. These eraseblocks start at 128KB.

For the moment, UBIFS, while immediately important to embedded Linux developers, isn’t going to make that much of a difference to Linux desktop and server performance. That’s because most modern flash-memory drives use emulation layer FTL (Flash Translation Layer) that presents a block interface to the operating system. However, as both hardware and operating system developers start enabling UBIFS access to conventional flash devices we’ll be able to get directly to flash storage, and we should see a vast increase in flash and SSD performance.

A storage improvement that will matter sooner to users is that the new mainstream ext4 Linux file system now includes delayed allocation, aka allocate-on-flush. Despite the name, which sounds like a bad junior-high potty humor, it’s actually a technique that can greatly improve hard drive write performance. The technique has been used before, notably in the controversial Reiser4 file system. This technique works by not writing data immediately to your drive. So far, so much old news. Systems have been caching write data in RAM for ages. In older storage routines, however, the system does burn time allocating the disk structures even though nothing is written. That may not sound like much of a delay, but it’s clearly makes a difference on systems with multiple writes like say a database server. For example, delayed allocation is also used in high performance file systems like Sun’s ZFS.

Ext4 can also handle extremely large drives. How large? Try 1024 petabytes per volume. Today’s top supercomputers typically only access a few dozen petabytes at most. I predict that you’ll soon be seeing ext4 on most high-end Linux servers.

Number five on my list is more of a collection of changes rather than a particular improvement. With this version, Linux has added native and improved support to many network devices including ones from Atheros, Intel and Renesas. In addition, netfilter, the foundation software for Linux’s firewall now has greatly improved IPv6 support.

None of these changes, taken individually, are game-changing the way that the inclusion of KVM (Kernel Virtual Machine) was in the 2.6.21 kernel. KVM lead to a totally Linux-based virtualization system and then Red Hat incorporating KVM’s developers into its own virtualization efforts.

In the long run, though, I can see these improvements to storage, firmware management and networking leading to more companies deciding that Linux is the operating system for their mission-critical work. Slowly, but surely, we can see Linux improving. Windows? Well, I’m not holding my breath.