Linux 2.4.0 Test2 Almost Ready for Prime Time

out of control sent us a quote from Linus from the kernel dev "There's a "test2" kernel out there now, integrating most of the -ac patches, and some code that wasn't in -ac. Normally, when you integrate almost 5MB of patches, bad things happen. This time, a miracle occurred. As I uploaded the resultant kernel, a specter of the holy penguin appeared before me, and said "It is Good. It is Bugfree". As if wanting to re-assure me that yes, it really =was= the holy penguin, it finally added "Do you have any Herring?" before fading out in a puff of holy penguin-smoke. Only a faint whiff of rancid fish remains as I type in these words.. In short, not only are most of Alan's patches integrated, I have it on higher authority that the result is perfect. So if it doesn't compile for you, you must be doing something wrong. Use a mirror.

Re:Has anyone ever noticed?

It's almost as if there's a bunch of geeks in Vegas betting on when each development release of what kernel will be released.

There are, and I just lost my shirt over this one. Now where will I hang my pocket protector?

Re:And in other news...

Of course Anonymous Cowards are the most humourous, most informed, most experienced users out there. It's the slashdot paradox. Uhh, yeah...

You should see the cookies slashdot has placed on my machine to track me!

www.slashdot.org FALSE / FALSE 1236522993 user %2532%2534%2533%2531%253a%253a%256c%2575%2573%2565 %2572%2535
www.slashdot.org TRUE / FALSE 1238388690 sexual_orientation 7699925.18704385
.slashdot.org TRUE / FALSE 1238388690 sexual_orientation 7699925.18704385
www.slashdot.org TRUE / FALSE 1238388845 soc_sec_num 1709714.88580108
.slashdot.org TRUE / FALSE 1238388845 soc_sec_num 1709714.88580108
www.slashdot.org TRUE / FALSE 1238408765 last_time_you_brushed_teeth 7630727.50531137
.slashdot.org TRUE / FALSE 1238408765 last_time_you_brushed_teeth 7630727.50531137
www.slashdot.org TRUE / FALSE 1238412245 high_school_gpa 1181069.01179999
.slashdot.org TRUE / FALSE 1238412245 high_school_gpa 1181069.01179999
www.slashdot.org TRUE / FALSE 1238412236 iq 4749934.93407965
.slashdot.org TRUE / FALSE 1238412236 iq 4749934.93407965
www.slashdot.org TRUE / FALSE 1238410318 religion 7864276.77143365
.slashdot.org TRUE / FALSE 1238410318 religion 7864276.77143365
www.slashdot.org TRUE / FALSE 1238412307 mothers_maiden_name 3729926.00314319
.slashdot.org TRUE / FALSE 1238412307 mothers_maiden_name 3729926.00314319

Re:So what is the biggest feature of 2.4?

you might want to check joe pranevich's article on 2.4. its called "Wonderful world of Linux 2.4" and you can find it http://linuxtod ay.com/news_story.php3?ltsn=2000-05-13-003-04-NW-L F-KN [linuxtoday.com].

i believe that udf support is added to 2.4. i dont believe that any journaling system (xfs/jfs/ext3/reiserfs) will make it into 2.4 but you can alway patch you kernel with reiserFS patch and get (imo) stable and fast journaling system. :)

Re:Ready for testing yes, not prime time

The I/O problems are fixed in 2.4.0-test2, which is what the announcement is about. VM is still shaky (which has an impact on I/O, naturally), but that is not related to block I/O.

2.4.0-test2 contains a largely reworked I/O scheduling layer and several elevators to pick and choose from.

Hopefully the vision was true...

...unless the holy penguin was asking for RED herring.

Yay

Linux 2.4.0-pre alpha beta-open test 2.5 is almost ready for prime time, to be followed by Linux 2.4.0-pre alpha beta-open, test 2.6, up to pre alpha beta-open test X, which I'm sure will all have extensive coverage on Slashdot.

Has anyone ever noticed?

Has anyone ever noticed that Slashdot follows kernel releases like ESPN follows box scores? It's almost as if there's a bunch of geeks in Vegas betting on when each development release of what kernel will be released.

What else do I have to upgrade?

Hi,

I've been sticking with 2.2(.16) until now, but if Holy Linux says it's perfect, I'd be willing to give 2.4 a try.

However, I have to ask: What other parts of the system have to be upgraded in order to make a smooth transition? Do I only have to compile the new kernel put it in /boot and shutdown -r now or are there any libraries or tools I need to upgrade as well? I've heard that the ipchains code has been rewritten (again?)... What about USB?

Re:What else do I have to upgrade?

Lookup the upgrade notes on this [kernelnotes.org]webpage.

Not quite perfect.

Viro still holds a firm grip on the VFS, and refuses to make it stackable. Worse than that, the VFS has specific ext2 functionality built into it. It's a "virtual filesystem" as long as you can make your filesystem look and work like ext2.

Now there's a harebrained idea to add "generic" journaling functionality to the VFS. I assume this is so that when ext3 is finally ready, the VFS will support it well, and all other filesystems will have to then look like ext3.

Take a look at the enormous hacks the HFS and ReiserFS have had to make to work around Alexander Viro and his Virtual Ext2 Filesystem.

Microsoft make it nearly impossible to write new filesystems for Windows NT, because they want everyone to use NTFS. Viro's doing the same thing. So why is it tolerated in an open-source OS?

The reason 2.4 has no journaling filesystem is that there are roadblocks in place to keep it that way. Ext3 will be the first journaling filesystem in Linux. Not because it will be the first journaling filesystem, or the best, but because it will be the one properly supported by the VFS ("Viro File System").

The Reiser-Viro flame wars aside, the filesystem cartel is doing serious damage to Linux. Linux should have a generic, capable, stackable VFS that isn't tied to a specific filesystem, and doesn't provide special support for preferred filesystems.

Adding to the problem is that the VFS is very poorly documented. Changes are made without any foreshadowing. The best documentation available is the source code for the Ext2 filesystem. And that is sad.

Maybe Linus will intercede to provide a better VFS. Maybe the Stark Fist of Removal will pay Viro a visit.

This post is not meant as a flame. The VFS is a serious issue. Linux could have had a journaling filesystem by now.

Grassroots movement to get ReiserFS merged.

I'd really like to see ReiserFS merged with the 2.4.0 kernel. I've been using ReiserFS 3.5.19 made available with the Linux-Mandrake 7.1 release, and I'm very happy with it. ReiserFS has survived several planned power outages and just keeps on ticking. By the way, the Linux-Mandrake installer even sets up the partition on which /boot exists with the notails option in /etc/fstab.

Read the testimonials on the ReiserFS homepage [devlinux.com].

A journaling filesystem is a very high profile Killer Feature. Having journaling in 2.4.0 would make Linux an even more obvious choice where data integrity is of paramount importance.

Lets start a grassroots movement to have ReiserFS merged with 2.4.0!

Re:Not quite perfect.

Since Linux is so open and all, couldn't Reiser just patch VFS itself? Isn't Linux GPL'd to prevent just this sort of thing?

Oversimplification...

If there were others doing VFS hacking, this would likely have some of the following effects:

• They might trample on one another.

  I change this, you change that, we break each others' code.

  This is different from device drivers, which are pretty independent of one another; the pervasive use of VFS in ext2 means that changes have to filter through someone in order for there to be hope of coherency.

• Linus may accept Al Viro's changes, even when they involve changes of VFS design, but be reluctant to accept others' changes to VFS design.

  Note that if Linus accepts changes from other people, as well as Al Viro, nothing stops Al from submitting patches that essentially reverse out others' changes in favor of his own. That would be not nice, to be sure.

  The side-effect of "patch preferences" is that if Linus accepts changes preferentially, those that aren't preferred won't necessarily take this gracefully, and may decide that there's no point to trying to work on VFS if their efforts are doomed to be ignored.

  The strong comments Hans Reiser has made indicate that he falls into the "won't take this gracefully" camp.

Reiser has suggested that there's a "Red Hat" conspiracy; I don't believe that, but it is sure that there have been some disagreements between ReiserFS developers and Al Viro...

Re:Not quite perfect.

Not meant as a flame, eh? :-)

Seriously, Al Viro is the only one standing up and doing VFS work, and informing Linus of his changes. I don't see anyone else actively hacking on the VFS, and then trying to push their changes through to Linus.

I'm a driver hacker not a VFS hacker so I'm not gonna comment on whether the current changes are good or bad. But I will say that Al Viro is the most active at pushing VFS patches straight to Linus. Further, he does post things on linux-fsdevel describing his ideas and designs. It's little wonder his changes go in.

If that situation needs to be changed, someone has got to sit down, code a better solution, and advocate it with Linus. Not just whine on Slashdot.

Jeff

P.S. I don't want to give the impression that Al Viro is the only one working on VFS. But merely wish to point out that he is the most active at pushing patches to Linus currently.

And in other news...

And in other news, more fixes and features were added to Free|Net|OpenBSD last night, bringing them one step closer to their next release.


"I shoulda never sent a penguin out to do a daemon's work."

Ready for testing yes, not prime time

The test series still have problems, notably with the VM and with I/O throughput.

For most people the test series perform _very_ poor compared to the 2.2 series when it comes to disk thoughput. 2.4-test is as slow as 1/5 of 2.2 for some.

But, 2.4-test is ready for testing. Definitely. Get the kernel, build it, run it, stress it. The developers need all the input they can get. If you have the time, then follow LKML from the archives (from kernelnotes.org or elsewhere), and respond with a benchmark/feedback every time a developer posts a patch.

The 2.4 series has a large number of optimizations over the 2.2 series, so most of the kernel should run a lot better than 2.2. But if your disk throughput is low and your kernel swaps unnecessarily, those other optimizations get you nowhere. AFAIK the only performance-related problems in 2.4-test is I/O and VM related. Once these are fixed, 2.4 is going to be the leanest kernel of them all.

Herring?

No, no, no. It's the finnish pronunciation which is causing all the problem. Just as "Linus" is really pronounced "Leanus", "herring" is, in fact, "hearing". So the penguin, who obviously doesn't speak very good english, was merely asking if Linus had heard correctly.

Either that, or he was accusing him of whoring...

XOX DOM

Re:Not quite perfect.

Patching the VFS is a solution, but not a good one. It means your filesystem is much harder to maintain, and that it can never be included in the kernel distro.

Most people use what's there when they run "make menuconfig", if they even compile their own kernels. The vast majority of Linux users would not compile their own kernel, but just use whatever RedHat/SuSE, etc. provide. Meaning a kernel component distributed as a patch will not be adopted, unless a distro adopts is as a standard non-standard part (like the TurboLinux clustering, and Reiser in SuSE).

If a filesystem could be loaded as a module -- meaning it wouldn't need to patch the VFS -- then people could still use it easily, even with stock kernels. Just download the TGZ, RPM, DEB or whatever and install it. Because a patch is required, most people will not use it.

Thus the lock-in.

SOrt of...

The Linus interview in Linux Magazine (Issue 1.1) makes a reference: "When a bug is found, Alan sends me a patch, and I sprinkle holy penguin pee on it, and it magically becomes official."

Re:Grassroots movement to get ReiserFS merged.

Such a merge is very very easy:

1) Reiserfs folks should start getting involved in everyday Linux-fs development, instead of sitting in their cathedral.

2) Reiserfs folks should start posting useful patches to the linux-kernel mailing list. Patches that benefit all filesystems and the generic architecture of Linux.

3) just post the patch in two parts: generic changes and lowlevel FS changes. Such patches are posted and merged on an everyday basis, eg. Linux now has a shared-memory filesystem!

It's not at all up to Linus to do the merge. It's the *Reiserfs folks* who should get more involved with the Linux kernel and should learn how to merge things. There were similar or bigger projects merged lately, for example USB, RAID, LVM, framebuffer subsystem. So a merge is easy: JUST DO IT, and stop whining, please.

compile != bug-free

The headline seemed to indicate that this release was "BugFree" and that "if it doesn't compile for you, you must be doing something wrong". Anyone with CS 101 experience knows that just because it compiles, doesn't mean that it's "BugFree".