Linux 2.6 Kernel Stability Freeze 378
An anonymous reader writes "Linux Creator Linus Torvalds released the 2.6.0-test7 Linux development kernel today and declared a "stability freeze". It has been made quite clear that from this point only "strictly necessary stuff" will be accepted, clearing the way for an official 2.6.0 release sooner than later... possibly at the end of this month."
Not "possibly at the end of this month" (Score:5, Informative)
Linus wrote: In other words, this should calm things down so that by the end of October we can look at the state of 2.6.0 without having a lot of noise from 'not strictly necessary' stuff."
That is, at the end of October he will "look at the state of 2.6.0". That's quite different from shipping it.
2.6 seems unimportant for me (Score:3, Informative)
Maybe I'll have to wait until I get a TCQ-enabled drive and see if that makes a difference.
Re:Reiser 4 (Score:1, Informative)
Re:Blah blah (Score:2, Informative)
I've not had such luck with XP as it lumps most everything onto one IRQ and then stutters as 6 devices fight over the same IRQ. The MS provided NEC USB 2.0 PCI card driver likes to BSOD too. I expect the OS to be able to handle a machine stuffed full of cards (AGP, 4 PCI, 1 ISA).
I'll admit though that from test3 to test6, the 2.6 kernel no longer acknowledges my BIOS setting that's supposed to keep PCI cards off IRQ 5 (for my ISA soundblaster), but I can live without sound (not to mention this is a beta and my problem is logged). I can't live with an OS that constantly stutters about and crashes all the time, which is what XP does.
Re:2.6 seems unimportant for me (Score:3, Informative)
This should make the desktop smooother.
Re:Is it faster? (Score:2, Informative)
www.kernel.org
2.4.23-pre6 is the latest.
Get your facts straight
Re:2.6 seems unimportant for me (Score:2, Informative)
With mozilla compiling in the background and vanilla test4, it's very hard to position my mouse pointer accurately on the screen while Mozilla is parsing a new page. Adding Con's patch fixes things to the point that if things didn't take longer to load, I wouldn't even notice that the compile was occurring.
This is on a pretty low-end system though ->K6-2 400 w/384MB
Re:Stability? (Score:5, Informative)
I've been using the 2.5 series since 2.5.66 or so. The main reasons I recommend 2.6 are:
These are the ones I can think of off the top of my head. I haven't used the built-in IPSEC yet, and software suspend still doesn't work properly on my laptop, but it's not far off. 2.6 will be a pretty sweet series.
Re:You can boot into Reiserfs (Score:3, Informative)
Because you rarely write to the boot partition, you shouldn't mount it, and it's a bitch to tell GRUB to ignore the length of the journal.
Re:Radeon FB fixed? (Score:2, Informative)
Re:Reiser 4 (Score:5, Informative)
The filesystem is getting reasonably stable.
This weekend we hit a bug in space reservation, which we can't reproduce yet but probably isn't too hard to find by code inspection. There is some thought that the assertion not the space reservation is buggy, in any case we'll release a snapshot after it is fixed.
Our performance is generally wonderful and getting better.
It has the following weakpoints:
* We allocate a "jnode" per unformatted node in the filesystem. The traversing of these jnodes consumes more CPU than performing the memcpy from user space to kernel space when doing large writes. I don't yet really understand on an intuitive level why this is so, which is a reflection on my ignorance as it is consistent with stories I have heard from other implementors of filesystems who found that eliminating per page structures was an important part of optimizing large writes. We will fix this by creating a new structure called an extent-node that will exist on a per extent basis, and this will probably cure the problem. This will greatly simplify parts of our code for reasons I won't go into, and it will also take us 6 weeks to do it. I don't think users should wait for it, and so we will ship without it.
* Our dbench performance was poor, has improved due to coding changes, and we need to test and analyze again. Perhaps more fixes will be needed, we can't say yet.
* Our fsync performance is poor. We will pay attention to this next year, frankly, after we have fully implemented the transactions API. At that point we will say something like, if you care about fsync performance you should be using the transactions API and/or sponsoring us to tune for NVRAM, users will say back "but our legacy apps on hardware without NVRAM matter!", and we will grudgingly but effectively tune for this because we care about real users too.;-)
Nikita recently invented and implemented a clever bit of code that keeps track of the highest node in the tree that spans a directory, and then performs repeat lookups within the same directory starting from there rather than the root. This is a nice answer to those who keep asking me, wouldn't it be faster to have separate trees for each directory? Now I have better answer for them --- nice work Nikita. It also has the nice side effect of reducing spin lock contention on the root node for 4-way SMP.
I am hoping to move my laptop to SuSE 9.0 running reiser4 sometime this week, and I am hoping we will ask for more outside testers to help us find bugs at that time. While I have mentioned only the performance flaws in this email, our overall performance seems to leave little doubt that the filesystem as-is is far better than V3, and even though it will get much faster with another year or so of tuning, if now we are the fastest available on Linux, we should be shipping now (assuming we find no new bugs in the last round of internal testing).
Benchmarks can be found at www.namesys.com/benchmarks.html
As you can see in those benchmarks, in V4 tails IMPROVE performance due to saving IO transfer time. This is a great improvement over V3, and generally speaking V4 stomps all over V3 performance. It also scales better, has plugins, and improves semantics a little bit (big semantic improvements will be in the next major release not V4).
You'll also notice that we increased the size of the fileset to be more fair to ext3, and we tested some ext3 configurations Andrew Morton suggested testing.
--
Hans
Re:Is it faster? (Score:3, Informative)
That's called buffered I/O and is a standard feature of modern operating systems. Where it gets dangerous is that Windows doesn't force you to manually unmount removable disks before pulling them out, which can easily result in data loss. But that's what the little light is for next to those drives. If the light is on, don't take the disk out or you will lose data.
Oh, and always stop the hardware before removing USB or firewire storage devices as on Windows that's the only way to be sure that all the data has been written to them.
Re:You can boot into Reiserfs (Score:3, Informative)
Yeah, that was a bitch.
P
Re:Stability? (Score:2, Informative)