Linux Kernel 2.6.21 Released

diegocgteleline.es writes "Linus Torvalds has released Linux 2.6.21 after months of development. This release improves the virtualization with VMI, a paravirtualization interface that will be used by Vmware. KVM does get initial paravirtualization support along with live migration and host suspend/resume support. 2.6.21 also gets a tickless idle loop mechanism called 'Dynticks', built in top of 'clockevents', another feature that unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel parameter-line, support for the PA SEMI PWRficient CPU and for the Cell-based 'celleb' Toshiba architecture, NFS IPv6 support, IPv4 IPv6 IPSEC tunneling, UFS2 write, kprobes for PPC32, kexec and oprofile for ARM, public key encryption for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, some new drivers and many other small improvements."

Tickless only for x86 now, still good news

[MarcQuadra]

I follow prerelease kernels and I've been waiting for this. I've found that running my VMWare hosts and guests with tickless, low-HZ, voluntary-preempted kernels is seriously reducing the overhead you get when you run more virtual CPUs than real ones in your box.

I can't wait for it to mature on PPC, MIPS, and x86_64! Right now it's 32-bit x86 only.

Re:Meh

[FudRucker]

personally i hate using an initrd.img and prefer to build ext2 & ext3 support right in the kernel making initrd unnecessary, if you compile file system support as a module you will need an initrd.img too so insetead of selecting an "M" select "*" you could try that...

P.S. i never use reiserfs so i can not say if this works with reiserfs or not...

You joke,

[StarKruzr]

but I wonder if we're ever going to see 2.8 at this rate. The current kernel revision is MILES away in technology from 2.6.0. What will it take to move to 2.8, or (dare I say it?) 3.0? What qualifies as a major enough change?

Re:OMG F1r5t P054

[justinlindh]

Stop it. This isn't the GameFAQs forum, and nobody cares if they're the first post here. If you don't have anything to contribute, then don't post.

On topic:
All of this built-in virtualization stuff sounds great. How long, on average, does it take the Ubuntu repositories to receive new kernels?

Mactel MBP C2D

[JumboMessiah]

As an owner of a Macbook Pro, I've been waiting for this to get released. The Dynticks integration will (hopefully) help lower power consumption and heat output. Though this will help reduce heat and power on all platforms, those running Linux on a MBP C2D know it's hard to keep the fans from spinning up from relatively little activity.

Next up is to get ATI to actually support any power saving features in fglrx on the MBP C2D and give the mAdWiFi [madwifi.org] guys more time to work out the features on the Atheros AR5008.

OSX, right now, still has a significant advantage in keeping heat and power consumption down. Even though, I imagine some will testify that even OSX is having a hard time with it...

Here's to testing out 2.6.21 tonight :)

Re:Sooner or later...

[ctr2sprt]

Yeah, the absurdly long kernel command lines in Linux really bug me. It's a symptom of the suckiness that is the PC BIOS, so I'm not really blaming the Linux people, but there are better solutions and have been for years. The FreeBSD loader [freebsd.org], for instance, is capable of loading the kernel and any modules required to bootstrap the system, reading configuration files, and running Forth (!) scripts. Such a loader would completely eliminate the need for initrds on nearly all systems[1] without sacrificing any power. You could also emulate Openboot or EFI - or more realistically a subset of them - using the PC BIOS to prepare for the future.

[1] initrd is a really awesome feature and it shouldn't go away. But it's massive overkill the way it's typically used, which is to load modules required to mount the root filesystem.

Re:Does it still crash after 49.7 days??

[Tom]

It doesn't and never did. However, the uptime clock wraps around after 497 days. Took me two hours of finding out why the box rebooted (and then why there was no indication of the reboot in the logs) one day to research that. That same box has since looped the clock a second time. So I can say for sure it stays up for more than 50 days. :-)

Re:Does it still crash after 49.7 days??

[AaronW]

As far as I know, Linux never had a 49.7 day problem, but it did have a problem at 497 days. I have a machine at home running the 2.4.20 kernel and every 497 days my uptime restarts, but it hasn't crashed. It's gone through 2 rollovers so far and has been up for over 3.72 years. It will hit its next rollover around September. I really need to build a new server... I just don't know if it will be as reliable as this one has been.

eCryptfs public key

[omnirealm]

The public key support for eCryptfs can handle more than just public keys. It includes a communication mechanism with a user daemon that can be queried from the kernel on file open events. There is a pluggable key module interface accessible through that daemon. OpenSSL is currently implemented, but there is nothing stopping anyone from writing a module to use GnuPG or any other key management/encryption backend, all in userspace. The module just needs to accept a key signature, and it can perform encryption and decryption based on whatever that signature refers to.

In other news, eCryptfs has recently been given the go-ahead for inclusion into Fedora:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=218556 [redhat.com]

In the meantime, you can grab all the userspace stuff from the eCryptfs SourceForge site:

http://ecryptfs.sourceforge.net/ [sourceforge.net]

Re:Does it still crash after 49.7 days??

[Tack]

It doesn't and never did. However, the uptime clock wraps around after 497 days.

I guess that one got fixed at some point:

[root@blade1 ~]$ uptime
18:00:25 up 622 days, 23:00, 1 user, load average: 0.17, 0.22, 0.29
[root@blade1 ~]$ uname -a
Linux blade1.[redacted] 2.6.9-11.ELsmp #1 SMP Wed Jun 8 17:54:20 CDT 2005 i686 i686 i386 GNU/Linux

Re:Bloat?

[HomelessInLaJolla]

I had begun making a similar observation to myself towards the 2.4.20+ line and definitely when 2.6 came out. It correlated nicely with the media increase in Linux coverage, the size and comprehensive nature of desktop environs like KDE and Gnome, the size of Xorg/Xfree86, and the increasing popular emphasis on web applications and the tion of HTTP and file-sharing protocol network usage over nearly anything else (spam excepted). I've almost decided that the computer programming age, as an affordable hobby for the non-specialist, is nearing the end of its lifetime. In a few more years you'll have the option of working with entirely standardized/commoditized/completely controlled (corporate DRM style) equipment or, if that doesn't appeal to you, then you'll have to go off a polar deep end and spend absolute bricktons of time and money assembling a system using a soldering iron, a breadboard, and specialty chips ordered from remote clearinghouses in China or Russia.

Re:Meh

[giorgosts]

My feisty has a 35% chance of mounting correctly the swap and ntfs partitions. On other occasions it boots ok, most of the times displays error and I have to reboot. I have the ext3 and swap partitions on PATA disk and ntfs on a SATA. Anyone else experienced that?

I also notice the new feisty to be much faster, but when under load, desktop slows down considerably. On edgy, however hard you loaded the machine, there was always the extra power for sth else if you wanted.

Feisty looks feels like a windows machine now.

Where is - REISER4 - the BEST FILESYSTEM ever.

[Anonymous Coward]

REISER4 - THE BEST FILESYSTEM EVER.

You can read more here:

http://linuxhelp.150m.com/resources/fs-benchmarks. htm [150m.com]
http://m.domaindlx.com/LinuxHelp/resources/fs-benc hmarks.htm [domaindlx.com]

| FILESYSTEM | TIME |DISK |
| TYPE |(secs)|USAGE|
 
|REISER4 lzo | 1938 | 278 |
|REISER4 gzip| 2295 | 213 |
 
|REISER4 | 3462 | 692 |
|EXT2 | 4092 | 816 |
|JFS | 4225 | 806 |
|EXT4 | 4408 | 816 |
|EXT3 | 4421 | 816 |
|XFS | 4625 | 779 |
|REISER3 | 6178 | 793 |
|FAT32 |12342 | 988 |
|NTFS-3g |10414 | 772 |

Column one measures the time taken to complete the bonnie++ benchmarking test (run with the parameters bonnie++ -n128:128k:0). The top two results use Reiser4 with compression. Since bonnie++ writes test files which are almost all zeros, compression speeds things up dramatically. That this is not the case in real world examples can be seen below where compression does not speed things up. However, more importantly, it does not slow things down either.

Column two, Disk Usage: measures the amount of disk used to store 655MB of raw data (which was 3 different copies of the Linux kernel sources).

OR LOOK AT THE FULL RESULTS:

|File |Disk |Copy |Copy |Tar |Unzip| Del |
|System |Usage|655MB|655MB|Gzip |UnTar| 2.5 |
|Type | (MB)| (1) | (2) |655MB|655MB| Gig |
 
|REISER4 gzip | 213 | 148 | 68 | 83 | 48 | 70 |
|REISER4 lzo | 278 | 138 | 56 | 80 | 34 | 84 |
|REISER4 tails| 673 | 148 | 63 | 78 | 33 | 65 |
|REISER4 | 692 | 148 | 55 | 67 | 25 | 56 |
|NTFS3g | 772 |1333 |1426 | 585 | 767 | 194 |
|NTFS | 779 | 781 | 173 | X | X | X |
|REISER3 | 793 | 184 | 98 | 85 | 63 | 22 |
|XFS | 799 | 220 | 173 | 119 | 90 | 106 |
|JFS | 806 | 228 | 202 | 95 | 97 | 127 |
|EXT4 extents | 806 | 162 | 55 | 69 | 36 | 32 |
|EXT4 default | 816 | 174 | 70 | 74 | 42 | 50 |
|EXT3 | 816 | 182 | 74 | 73 | 43 | 51 |
|EXT2 | 816 | 201 | 82 | 73 | 39 | 67 |
|FAT32 | 988 | 253 | 158 | 118 | 81 | 95 |

Each test was preformed 5 times and the average value recorded.
Disk Usage: The amount of disk used to store the data (which was 3 different copies of the Linux kernel sources).
The raw data (without filesystem meta-data, block alignment wastage, etc) was 655MB.
Copy 655MB (1): Copy the data over a partition boundary.
Copy 655MB (2): Copy the data within a partition.
Tar Gzip 655MB: Tar and Gzip the data.
Unzip UnTar 655MB: UnGzip and UnTar the data.
Del 2.5 Gig: Delete everything just written (about 2.5 Gig).

http://lkml.org/lkml/2007/4/9/4 [lkml.org]

Language

[StarKruzr]

does not an arbiter of a versioning system make. :p

More things have changed between 2.6.0 and 2.6.21 than changed between 2.0 and 2.2.

How's that?

Re:Meh

[tinkertim]

personally i hate using an initrd.img and prefer to build ext2 & ext3 support right in the kernel making initrd unnecessary, if you compile file system support as a module you will need an initrd.img too so insetead of selecting an "M" select "*" you could try that...

Its not just the file system you need, its the ability to spin the drive containing said file system too :) Its legacy HW that's getting fuzzy , not file systems. Not really sure why you hate initrds so much?

The initrd does many more things than load drivers. What if you have an AoE based storage network with many disk-less stations needing to use an OCFS2 single system image? Initrd's can do neat things besides loading modules, have a look at linuxrc. You can bring network adapters to an up/link state, negotiate iscsi targets, download a boot config from a resource controller, all kinds of goodies. Complex networks need to do lots of things before pivot_root gets called, and we need complex networks.

piix hasn't been 'quite right' since 2.6.16.29 on most of the legacy servers using PATA (IDE) I still have up and working, many of us have been having a difficult time with it. But progress is progress, and this is good progress so I guess my move to all SAS will be sooner than later.

Re:Quite possibly.

[Daniel Phillips]

Just tried the latest kernel and it hangs on trying to fire up the second ATA instance. Not even a kernel oops, nothing. That's true whether I use the vanilla kernel or Red Hat's RPM. Something is screwed up, and from the sounds of it, there's more than one of us experiencing a failure at the same point, so that would be the obvious suspect.

This problem needs to go to lkml, and cc Andrew.