KernelNewbies:

Linux 2.6.30 was released on the 9th of June, 2009.

Summary: This version adds the log-structured NILFS2 filesystem, a filesystem for object-based storage devices, a caching layer for local caching of NFS data, the RDS protocol which delivers high-performance reliable connections between the servers of a cluster, a distributed networking filesystem (POHMELFS), automatic flushing of files on renames/truncates in ext3, ext4 and btrfs, preliminary support for the 802.11w drafts, support for the Microblaze architecture, the Tomoyo security module, DRM support for the Radeon R6xx/R7xx graphic cards, asynchronous scanning of devices and partitions for faster bootup, MD support for switching between raid5/6 modes, the preadv/pwritev syscalls, several new drivers and many other small improvements.

1. Prominent features (the cool stuff)

1.1. NILFS2, a log-structured filesystem

Contributor: NTT Labs (Nippon Telegraph and Telephone Corporation)

NILFS2 is a new filesystem which uses a log-structured design. What makes log-structured filesystems different is that they treat the whole disk as a consecutive list of blocks (called log). All the operations append data at the end of the log, they never rewrite blocks (except when there's no space left - in that case, new blocks are reclaimed from the start of the log). The advantage of this approach is that all modifications an creations are converted into sequential operations, which are faster. Crashes can't corrupt the filesystem. On mount, the filesystem detects the real end of the log, and continues working from that point.

Another advantage of this approach is that the log offers a coherent historical view of all the operations done in the disk in the past. This is called "continuous snapshotting" - snapshots of modifications done in all the filesystem at any time are created automatically due to the log-structure design, with no requirement of intervention from an admin, and with the filesystem size as the only limit. NILFS2 allows to access those snapshots and even mount them (on read-only mode).

NILFS2 is under development. Code: fs/nilfs2/. Filesystem web page: www.nilfs.org

1.2. POHMELFS and DST

Contributor: Evgeniy Polyakov

Recommended LWN articles: Distributed storage and CRFS and POHMELFS

1.3. Reliable Datagram Sockets (RDS) protocol support

Contributor: www.openfabrics.org (Particularly, Oracle)

RDS provides a high bandwidth, low latency, reliable inter-process communication protocol and transport system between the servers in a cluster. It provides a reliable connection between any two nodes in the cluster. This allows applications to use a single socket to talk to any other process in the cluster - so in a cluster with N processes you need N sockets, in contrast to N*N if you use a connection-oriented socket transport like TCP. In beta testing, RDS over infiniBand provided up to 60 percent performance improvement over Gigabit Ethernet for interconnect-intensive applications. RDS is already used by some products like Oracle and in Silverstorm's Quicksilver.

Code: net/rds/

1.4. Fastboot

Recommended LWN article: An asynchronous function call infrastructure

Contributor: Intel

Some parts of the kernel boot process can delay the whole process too many time (by kernel's standards): scanning in search of storage devices for a given controller, and searching for partitions, for example, can be slow, because the scanning is synchronous, only one device is scanned at a time, and the kernel has to wait for the devices. With this feature, those steps are done asynchronously, so the kernel can keep booting the rest of the kernel while the storage devices are scanned in parallel. This feature speeds up the total kernel boot time significantly

Code: (commit)

1.5. IEEE 802.11w (wireless management frame protection support)

Contributor: Atheros

The IEEE 802.11w standard is a proposed (still not approved) amendment to the IEEE 802.11 standard (wifi) that increase the security of its management frames. In this version Linux adds a preliminary implementation for this future standard, developed according to the current drafts.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13)

1.6. preadv()/pwritev() system calls

Recommended LWN article: Some new system calls

Contributor: Red Hat

These syscalls are a pretty straightforward combination of pread/pwrite and readv/pwrite. BSD systems have such system calls too, for example NetBSD

Code: (commit 1, 2, 3)

1.7. EXOFS, a filesystem for Object-Based Storage Devices

Recommended LWN article: Linux and object storage devices

Contributor: Panasas

Traditional storage devices offer a block-based interface. However, there's a new generation of experimental storage devices that are trying to offload some work from the host, and offer a higher-level interface: an array of objects. The OS interfaces with the objects, and the drive hides all the storage details, removing most of the low-level details of the filesystem. A traditional filesystem can then be easily implemented on top of this interface. The OSD interface works on top of SCSI.

In this release Linux adds support for the OSD protocol on the SCSI stack, and exofs, an implementation of a traditional unix filesystem that works on top of OSD storage devices.

libosd: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16),

EXOFS: fs/exofs/

1.8. NFS 4.1 preliminary support

Contributors: Panasas, Netapp and IBM.

NFS 4.1 is being developed at the IETF. From the many new features in NFSv4.1, this Linux version adds the mandatory-to-implement NFSv4.1 Sessions. Other features, Parallel NFS in particular, are still under development out of tree and will be added in later releases.

To enable this experimental new protocol (which is disabled by default) you need an updated nfs-utils.

1.9. FS-Cache, a caching filesystem

Recommended LWN article: A general caching filesystem

Contributor: Red Hat

FS-Cache is the Linux implementation of a cache layer for networking filesystems, similar to the CacheFS of other Unixes. With FS-Cache, data from the networked filesystems can be cached on the disk, speeding up operations.

This version adds support for NFS and AFS, but it's a generic layer that could be used by other networking filesystems or even non-networking (such as ISO9660).

Code: Slow-work related changes: (commit 1, 2, 3, 4), FS-cache (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16, 17 18, 19); AFS and NFS changes: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 16, 17 18), Documentation: Documentation/filesystems/caching/fscache.txt.

1.10. Tomoyo, an alternative Mandatory Access Control

Recommended LWN article: TOMOYO Linux and pathname-based security

Contributor: NTT DATA CORPORATION

There're currently two security subsystems: Selinux and Smack. Tomoyo is a new pathname-based access control.

(commit 1, 2, 3, 4, 5, 6, 7)

Tomoyo Web Site: http://tomoyo.sourceforge.jp/wiki-e/

1.11. Filesystems performance improvements

Shortly after the 2.6.29 release, lots of discussions occurred on LKML about disk I/O (summary available at LWN), how (and why) a fsync () call can take minutes, and the effect of getting a file zeroed rebooting just after a rename or a truncate. Some changes have been done to fix those problems: implicit internal fsync of a file after a rename or truncate in ext3, ext4 and btrfs, faster fsync() in ext3, default to data=writeback mode in Ext3, and improvements to CFQ. The flame has also brought the topic of atimes updates, and which has resulted into merging relatime and making it a default.

1.12. LZMA/BZIP2 kernel image compression

Contributor: Alain Knaff

The kernel compresses the kernel with GZIP, but this version adds support to compress the kernel image with the LZMA or BZIP2 compression algorithms. The kernel size is about 10 per cent smaller with bzip2 in comparison to gzip, and about 33 per cent smaller with lzma.

Code: (commit 1, 2, 3, 4, 5)

1.13. Microblaze CPU architecture

Contributor: Michal Simek, with donations from PetaLogix and Xilinx

This release adds support for the MMU-less Microblaze CPU architecture. It has been

Code: arch/microblaze/

1.14. Integrity Management Architecture

Contributor: IBM

Recommended LWN article: Integrity management in the kernel

The Trusted Computing Group(TCG) runtime Integrity Measurement Architecture(IMA) maintains a list of hash values of executables and other sensitive system files, as they are read or executed. If an attacker manages to change the contents of an important system file being measured, we can tell. If your system has a TPM chip, then IMA also maintains an aggregate integrity value over this list inside the TPM hardware, so that the TPM can prove to a third party whether or not critical system files have been modified.

Code: (commit 1, 2, 3, 4, 5, 6, 7)

2. Various core changes

3. PCI

4. Wi-Fi

5. Security

6. Networking

7. Ftrace

8. Filesystems

9. Crypto

10. DM/MD

11. Virtualization

12. Architecture-specific changes

13. Drivers

13.1. Storage

13.2. Graphics

13.3. Network

13.4. Input

13.5. Sound

13.6. V4L/DVB

13.7. USB

13.8. HWMON

13.9. Bluetooth

13.10. Staging drivers

Warning: The staging drivers are in a alpha development stage, and they can't even considered experimental, but they're included in the source tree in the hope of encouraging its development and stabilization

13.11. I2C

13.12. RTC

13.13. HID

13.14. MTD

13.15. FireWire

See also FireWire release notes at kernel.org.

13.16. EDAC

13.17. Serial

13.18. LEDs

13.19. ACPI

13.20. Various

14. Other sources about 2.6.30 kernel


KernelNewbies: Linux_2_6_30 (last edited 2017-12-30 01:30:00 by localhost)