Kernel Log: What's coming in 2.6.30 - File systems: New and revamped file systems (h-online.com)
Released mid-week, as is normal for the second phase of the development cycle, the third pre-release version of Linux 2.6.30 included mostly minor enhancements and fixes, although there were two code restructures.
The interminable discussions of the Ext3 and Ext4 file systems and the way they interact with other kernel subsystems have largely subsided. The H Open has reported on the early stages of these discussions – the occasionally abrasive discussion on the LKML (Linux Kernel Mailing List) continued for a further week, with a total of 650 emails, not counting other threads triggered by the discussion.
The debate has been far from fruitless and has led to the development of various modifications which Torvalds has integrated, in some cases immediately, into the main development tree leading to Linux 2.6.30. This part of the "What's coming in 2.6.30" Kernel Log series gives an overview of these and many other changes to the code for the various file systems supported by Linux.
Access time
At a relatively early stage of the above discussion, an old, previously much discussed issue affecting all file systems once more reared its head – when and how frequently should the kernel update a file's atime (last access time)? This information is of importance to only a handful of applications and each update of the atime requires a write process. This not only has a time overhead, it is also somewhat surplus to requirements for SSDs and laptops running on battery.
Spurred on by this, Matthew Garrett has produced a number of patches which result in the kernel now updating last access time just once a day (Relative atime/relatime). It took Linus Torvalds just a few hours to make this one of the first patches to be incorporated into the main development tree following the release of 2.6.29. A further patch from Garrett makes relatime the default. The old style behaviour can be restored using strictatime.
But even these changes, which many kernel hackers have long been calling for, did not satisfy everyone – Valerie Aurora (formally Henson) has listed various criticisms on her blog. Expect this one to run and run.
Latencies
A user reporting long latencies when applications use fsync() to flush the Ext3 write buffer when the kernel is working through large read processes prompted a discussion on LKML. The problem has been known about for several months, but the available workarounds were somewhat controversial.
Ext[2/3/4] file system developer Ted Ts'o put the blame squarely on application developers who, he opined, could save the file system a deal of work with a little more prudence. Other kernel developers disagreed. Ts'o has, however, already developed a number of less controversial patches for Ext3 and Ext4 which, according to his measurements, reduce latency and which have subsequently been incorporated into 2.6.30.
Subsequent tests by Torvalds, however, determined that some of the blame for latencies must be placed on the block layer's CFQ scheduler. Jens Axboe analysed the problem and quickly developed more changes which further reduce latencies. This will in some cases increase the speed of desktop systems not just measurably, but tangibly.
Latency II
Debate and details
This article only describes the most critical points and outcomes of the discussions on Ext3 and Ext4 mentioned above and their interaction with other kernel subsystems such as the block layer. Linux Weekly News (LWN.net) has taken a more detailed look at the discussion and the changes arising from it in the articles That massive filesystem thread and Solving the ext3 latency problem.
The articles "Linux Storage and Filesystem workshop" Day 1 and Day 2 also in part explore the issues discussed. The article ext4 an...
1 comment
[ 1.6 ms ] story [ 14.4 ms ] thread