Linux kernel 2.6.30 released

[microchip8]

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

http://kernelnewbies.org/Linux_2_6_30

[Knurpht]

I've been running the rc's, they are in Factory, and I must say that this kernel has meant an enormous improvement. Performance on my laptop overall increased.

[microchip8]

Originally Posted by Knurpht

I've been running the rc's, they are in Factory, and I must say that this kernel has meant an enormous improvement. Performance on my laptop overall increased.

I bet you've seen major performance improvements when using ext3? They made data=writeback the default which I don't agree with. (you can force ordered to default when configuring the kernel though)

[microchip8]

forgot to mention... or force data=ordered with a mount option

wtf we can't edit our posts in this Tech News subforum? That's rediculous

[j_xavier]

your objection to "write-back" vs "ordered" would be data integrity? please elaborate, it's not a subject I have given much thought.

[microchip8]

writeback is the less secure/reliable mode of ext3. It gives very similar data integrity protection as XFS. Meaning, in writeback mode, data gets flushed *after* meta-data is commited to disk and also there's no grouping during flushing (afaik). This means that a potential problem could arise where during a commit of meta-data suddently the system loses power. When that happens, the journal will have meta-data entries which point to non-existant data on disk since it did not have the chance to flush the data to disk due to the power outage. In this situation, during bootup and journal replay, the standard behavior of ext3 is to zero out any data which has not made it to disk but has meta-data entries in the journal which point to it. Basically, in writeback, the chance is higher that one will end up with garbage in files which were open/truncated when the power failure happened. In ordered mode, ext3 flushes data first to disk, then meta-data is updated which is more secure since during boot and journal replay, ext3 only needs to update the missing meta-data of files which were flushed to disk but during the power failure it didn't had the chance to update their meta-data. Ordered mode imposes some performance issues though which can be fixed with writeback at the expense of less data integrity. There's a patch floating around by Chris Mason (btrfs and former reiserfs developer) which introduces data=guarded to ext3 which balances the way ext3 treats data/meta-data commits. Hopefully, this patch will be added to kernel 2.6.31

My objections to making writeback the default for ext3 is that, if you're going to have less security so that you can improve the speed of a flawed file system like ext3, it's better you choose XFS or similar which will give you the same security as ext3's writeback in addition to things ext3 doesn't have like extents, allocate on flush, large file and very large partition support, etc