Linux 2.6.37 Released

diegocg writes "Version 2.6.37 of the Linux kernel has been released. This version includes SMP scalability improvements for Ext4 and XFS, the removal of the Big Kernel Lock, support for per-cgroup IO throttling, a networking block device based on top of the Ceph clustered filesystem, several Btrfs improvements, more efficient static probes, perf support to probe modules, LZO compression in the hibernation image, PPP over IPv4 support, several networking microoptimizations and many other small changes, improvements and new drivers for devices like the Brocade BNA 10GB ethernet, Topcliff PCH gigabit, Atheros CARL9170, Atheros AR6003 and RealTek RTL8712U. The fanotify API has also been enabled. See the full changelog for more details."

Comments

Kernel locking

[iONiUM]

Well I'm glad they officially fixed the kernel lock. Out of curiosity, how long until Ubuntu or Debian sees this integrated into their line? A year? Not trolling, I only started using Ubuntu recently, so I'm curious.

Re:Kernel locking

[Anonymous Coward]

Ubuntu will ship with this kernel in their next release Natty in April

Re:Kernel locking

[Anonymous Coward]

good question. My debian box was running 2.6.26. "Was" because I updated (via backports) to 2.6.32 to fix some kernel bugs that had been fixed in 2009. So, maybe a couple years.

Re:Kernel locking

[Cyberax]

Ubuntu in about 6 months, 2.6.37 should be in the 11.04 release.

In Debian Stable - in about 2 years (in the next release).

Re:Kernel locking

[turbidostato]

"Well I'm glad they officially fixed the kernel lock. Out of curiosity, how long until Ubuntu or Debian sees this integrated into their line?"

Don't know about Ubuntu but since Debian is already "frozen" towards its next release (codename "squeeze") you can bet it will be about two years from now, more or less.

Of course, you will see it much sooner on their development lines, "Testing", "Unstable" and/or "Experimental".

Re:Kernel locking

[lederhosen]

In debian it will be available soon in unstable, the RC is already available in experimental.

Package linux-image-2.6.37-rc7-686

        * experimental (kernel): Linux 2.6.37-rc7 for modern PCs
            2.6.37~rc7-1~experimental.1: i386

Re:Kernel locking

[Bj�rn]

And what about Fedora?

Re:Kernel locking

[Anonymous Coward]

It's not a complete removal of the BKL. There are still some drivers (and a couple of filesystems I think) that have not been converted. Selecting those in a config as a built in or standalone will re-enable the BKL. IIRC, the plan to have those corrected or obsoleted is scheduled for .38

Re:Kernel locking

[inode_buddha]

Check the "rawhide" repositories. Fedora tends to track the -rc kernels fairly closely with near-daily builds. Therefore it is likely that fedora will have this in rawhide within a day if not already.

Re:Kernel locking

[DissociativeBehavior]

According to the article all the critical code paths don't use this lock so you shouldn't see any performance improvements.

Re:Kernel locking

[korgitser]

And that would be the .38 special

Re:Kernel locking

[arth1]

Fedora 15 has a planned release date of May 10.
It will most likely have 2.6.37 (they're currently at .36, but several people have made .37-rc versions, and the deadline for version bumps and features isn't up yet).

Re:Kernel locking

[kbielefe]

It already is, for very liberal definitions of "integrated." :-)

Re:Kernel locking

[Anonymous Coward]

It is in rawhide now:

http://download.fedora.redhat.com/pub/fedora/linux/development/rawhide/x86_64/os/Packages/kernel-2.6.37-1.fc15.x86_64.rpm

Which means it will definitely be in the next release.

Re:Kernel locking

[micheas]

Debian experimental should have it within a week or two.

Debian is "Frozen" for the release of squeeze, so 2.6.37 will probably never make it into Debian unstable as it is likely that 2.6.38 will make it out the door before squeeze is released. (just a gut guess with no supporting evidence for the dates.) If my guess is right 2.6.38 will more likely make it into Debian than 2.6.37.

Ubuntu will push a new kernel out in about three months, I don't know if it will be 2.6.37

Re:Kernel locking

[Beardo the Bearded]

I've got the RC for Ubuntu and have used it for a month or two. It fixed the networking, so that after sleep it would actually connect to the network. For some reason, the driver was programmed to fill with random values so it wouldn't sync unless you rmmod / modprobe ath9k.

On the downside, the RC removes control of the backlight. What I'd like to see next is fixing the kernel so that the new generation of touchpads is recognized, or maybe something like ndiswrapper for other drivers.

Re:Kernel locking

[somenickname]

This kernel should trickle down to 10.04 LTS as well. One of the big complaints about the 8.04 LTS version was that hardware gets released so rapidly that a 3-5 year old kernel isn't going to support a lot of it. Even right now the Ubuntu 10.10 kernel (2.6.35) is in the 10.04 repos that are enabled by default.

Re:Kernel locking

[diegocg]

Note that the performance advantages of that change are zero. It's an aesthetical thing, so distros are not in eager of shipping it.

Re:Kernel locking

[Anonymous Coward]

I would say that maybe 2.6.38 will be on Ubuntu 11.04

2.6.38 will be a must have!

Re:Kernel locking

[Bootsy Collins]

Would someone mind explaining (for those of us who have some C experience, but aren't kernel hackers) what the Big Kernel Lock is? In particular, is this something that will impact the desktop user?

Re:Kernel locking

[mvar]

Somehow this question gives a strange deja vu

Re:Kernel locking

[bzipitidoo]

That's one reason I switched to Arch Linux. Updates make it in a lot faster. That's particularly nice for the browser.

Hoped I wouldn't experience downsides from that, but I have. I'd say Linux still isn't ready for the Year of Linux on the Desktop. These sorts of problems show the wisdom of holding off on kernel updates. I want Firefox updates right away. But kernel updates? Maybe not.

Kernel 2.6.34 and 35 had a problem in the e1000 driver, which seemed to affect only very specific motherboards, like in one of my computers. No networking was an especially inconvenient problem. I haven't stumbled over a neat way to downgrade in Arch, apart from a new installation from an old snapshot, so I simply used other computers until 2.6.36, and that fixed the issue. Going back to 2.6.33 or earlier wasn't a good option either-- those had other problems. Too many dependencies. Such as forcing an undo of a partial conversion from HAL to udev. I read that HAL is a mess, and will be abandoned for udev. Possibly the biggest change for version 1.9 of Xorg was a switch from HAL to udev.

Most of the nagging little problems are with the desktop. Don't know if reading from full sized CD-Rs has been fixed. Been fooling with lighter weight GUIs, specifically LXDE, and the automounting never has worked well. Why don't I just use KDE or Gnome? Don't like the sluggish feel of their interfaces. Shutdown on another of my computers has been random since around 2.6.30-- sometimes it works, and sometimes not. Used to always work. I have some ancient trackballs that connect to a 9 pin serial port. No luck getting Xorg to use such devices. Still can't ditch the proprietary NVidia driver for Nouveau. Am wondering when distros will offer btrfs as one of the options. Reiserfs is pretty old now, and dying, and ext4 hasn't thrilled me. But that age is nothing compared to the fact that FAT is still the easiest way to share files with Windows.

Re:Kernel locking

[Anonymous Coward]

It was a hacky way of providing SMP support that is less efficient than a non-blocking method. As things stand it will have no effect for almost anyone since all the core modules since they haven't depended on the BKL in a while.

Re:Kernel locking

[Pr0xY]

It's a fairly simple idea. In any place that two threads of execution (be them real threads or interrupts or whatever) could possibly access the same resource at the same time, locking must be used to ensure data integrity and proper operation of the code. The "Big Kernel Lock" is a system wide "stop the world" lock. This is a very easy way to make the code "correct" in the sense that it will work and not corrupt data. But the downside is that while this lock is held... everything else must wait. So you better not hold it for very long and while it is easy to get correct, it has pretty bad performance implications.

A better solution is a fine grained lock just for that resource, so the only threads of execution which need to wait are ones that are actually contending for that resource. The downside here is that it is much more complicated to get correct. So when implementing this, you have to be *very* careful that you got it right.

The BLK has been in the process of being removed and has been phased out of the vast majority of the kernel for a while, this change is simply enabling a build in which it doesn't even exist if you don't build any of the older drivers which don't use more fine grained locking.

Re:Kernel locking

[Anonymous Coward]

How about Mandriva?

Re:Kernel locking

[phantomcircuit]

The Big Kernel Lock is a Symmetric Multi Processing (SMP) construct. In order to make kernel operations atomic you lock the entire kernel. This works as a good initial locking mechanism because it's relatively easy to implement, it avoids issues like deadlocking very well.

The problem with the BKL is that it locks the entire kernel, even if processes are calling functions totally isolated from each other only one can be in the kernel at a time.

In practice the BKL hasn't been a big deal for a while now since the important (performance wise) parts of the kernel have had finer grained locking.

So It's pretty unlikely to have much effect if any on desktop users.

Re:Kernel locking

[Yossarian45793]

For those that aren't aware, the BKL (big kernel lock) hasn't caused any issues except purist angst for a very long time now. All of the performance critical kernel code was fixed to use fine grained locking years ago. This change is just to satisfy the people who are offended by the architectural ugliness of the BKL. In terms of performance and everything else that matters, the removal of the BKL has absolutely no impact.

Re:Kernel locking

[Anonymous Coward]

SMP support was added in 2.2 and the hard lock was a way to transition toward fine locking later. it only allows one thread to be in kernelspace at a time and as a result, causes problems when you try to scale the system. In other words, SMP gave the kernel support for parallel processing which is incredibly useful for running multiple tasks at the same time.

http://www.ibm.com/developerworks/library/l-linux-smp/

http://book.chinaunix.net/special/ebook/Linux_Kernel_Development/0672327201/ch09lev1sec8.html

Re:Kernel locking

[Anonymous Coward]

It's pretty much what it says it is :
One big lock (as in concurrent programming locks, mutexes, etc) that is used by about any part of the kernel.
It makes it easy to make the os concurrency "safe" but scales poorly with more than 2 processors (each time any driver requires the lock, ALL the other parts that are being executed on other cores have to be put on hold until the lock is released)
It's being replaced by fine-grained locks which are well... small locks that only protect independent parts of the code

You have pretty much the same problem in interpreted languages like python or ruby, see Global Interpreter Lock

Re:Kernel locking

[Yossarian45793]

The BKL was a hack added in Linux 2.0 to support multiprocessor machines. It was ugly but expedient (like most engineering solutions). Over time, multiprocessor support in the kernel has gotten much better, and the BKL has become less important, up until now when it's so unimportant it can be removed entirely.

Nobody, especially not desktop users, will notice any change from its removal.

Re:Kernel locking

[AntiGenX]

Put simply, when you have many independent bits of code competing for finite shared resources/time within the kernel (this is different than code just running in user space), you have to put locks on them so that only 1 thread can access them at a time. Once a lock is released then the another thread gets a turn. With a big lock, only one lock exists for every resource. Although a thread may only need access to a single resource, all of the resources get locked.

The alternative is to implement more fine-grained locks on each resource or set of resources. This allows two threads that are using different kernel resources to potentially execute in parallel. The danger is it's more complex and requires careful coding to avoid deadlock or race conditions. That help?

http://blog.internetnews.com/skerner/2010/11/linux-2637-kills-the-big-kerne.html

Re:Kernel locking

[Korin43]

Arch does have an LTS kernel (although "long-term" in Arch is like 6 months), which you can use if the current version is broken. I used it for a while when wine + some kernel version caused World of Warcraft to not work. Hope this helps if you problems in the future.

pacman -S kernel26-lts

Re:Kernel locking

[petermgreen]

In debian it will be available soon in unstable
Afaict the general policy in debian is to only upload stuff to unstable if it's targetted at (note that targetted at doesn't nessacelly mean will be in) the next stable release. It seems unlikely that debian would try to push a new kernel version at this point in the release cycle.

So I wouldn't expect it to hit unstable until after squeeze releases.

Re:Kernel locking

[pinkeen]

Distro's with rolling releases - probably not more than a week or two. I've read somewhere that Ubuntu is considering change to rolling releases model too.

Re:Kernel locking

[UnknownSoldier]

Agreed. I've been using Linux off and on (started with Slackware ~1.0, kernel 0.99, yeah _that_ long ago) The running joke is that it is always $(Year)+X for the year of the Linux desktop -- seriously doubt it will ever happen for the masses. Windows + Mac OS X are just too entrenched and "good enough." As a programmer/geek, if I don't have time to dick around getting Linux to work, the rest of the non-computer illiterates don't have a hope. It is easier to just recommend OS X to non-computer people.

Always cool to see "the little OS that could" continue to make progress though. :-) Drivers are Linux's strength (older hardware) and weakness (newer hardware.)

Re:Kernel locking

[macemoneta]

As mentioned, the 2.6.37 kernel is in Fedora rawhide now, and it works fine with the current (Fedora 14) release if you want (or need) to run it:

http://koji.fedoraproject.org/koji/buildinfo?buildID=212634

The official Nvidia driver installer compiles and runs cleanly against it, making early use easier.

Re:Kernel locking

[Anonymous Coward]

You could compile it yourself, or is that tricky in Debian and Ubuntu?

Re:Kernel locking

[deek]

Reiserfs is pretty old now, and dying, and ext4 hasn't thrilled me.

What features have you enabled in ext4? I'm running it on one of our servers, and I like the performance very much. It's even a debian stable machine, although I had to use a kernel from "testing" to properly enable ext4.

I've got extents, uninit_bg, and dir_index enabled, amongst other features. If you converted from ext3, then you probably don't have these options enabled. Even if you created the ext4 filesystem from scratch, some older versions of mke2fs won't enable these ext4 features by default.

Try giving ext4 another go. Maybe you'll like it more the second time around.

Re:Kernel locking

[TheRealGrogan]

It's a bit tricky in all of those so called "easy" distributions but not impossibly difficult. It's probably best to use the distributor's kernel sources and methods, but you don't have to if you make some changes to the system first. You have to be careful that you're not using features they've patched in to their kernels if you do that though.

I have Ubuntu 10.10 (actually Xubuntu with XFCE) on my netbook, and I have been using a regular kernel.org kernel (2.6.36.2 currently) without using an initrd or anything. This requires changes to fstab to use normal device nodes rather than the UUID. In Ubuntu I was previously using their sources and the alternate "Debian" method of building them.

https://help.ubuntu.com/community/Kernel/Compile

On redsplat distros (Fedora, RHEL) it won't boot without an initrd unless you manually create some hard device nodes in /dev first. (This is assuming it's still possible... I haven't tried one in a long time)

In all of those "easy" distros it sucks out of the box though... you have to install all the tools you'll need. (In *buntu that's usually just build-essential and libncurses5-dev for kernel)

Distros like Slackware, Gentoo, Arch and similar are pretty much meant for the user to roll their own kernels.

Re:Kernel locking

[El_Oscuro]

Please, if you need some serious firepower, you need the totally compatible .357 magnum

Re:Kernel locking

[afabbro]

Kernel 2.6.34 and 35 had a problem in the e1000 driver, which seemed to affect only very specific motherboards, like in one of my computers. No networking was an especially inconvenient problem.

And kind of an unnecessary one, considering that the e1000 module code is available for free download on Intel's web site, is GPL, and is very easy to build. My box with an e1000e may be running 2.6.18, but the e1000e module is Intel's latest 1.2.20.

Re:Kernel locking

[dmuir]

No, Ubuntu will not be changing to a rolling release, has never planned to, and probabily never will.

Re:Kernel locking

[davester666]

Fixed? How about total frickin anarchy running lose in your kernel. With no giant lock wielding a banhammer, kernel modules of all kinds will run rampant over anything and everything.

It will be complete chaos.

Re:Kernel locking

[bzipitidoo]

Maybe I will. I didn't do anything special with ext4, which means I got the default settings, whatever they are. Don't think I had noatime. Anyway, seemed like ext4 wasn't as fast as a fresh Reiserfs partition. Ext4 rattles the hard drive more, judging from the noise. No, I don't have any hard data from carefully controlled tests to know whether ext4 really is less efficient. But I do know ext2 with journaling (aka ext3) isn't that great. Rather use xfs than ext3. Like its predecessors, ext4 is still fundamentally block based.

And I'm perpetually short of hard drive space, which may sound crazy in these days of 1TB drives, but split that across several OSes, install massive games, apps, video files, and so forth and space goes quick. So I like tail packing in the file system, data compression, and anything else that saves space. I know, I know, that only gets a little more room, but I like to have it.

I've been holding out for btrfs. Not sure it's mature enough that I want to make the jump just yet, but I'm hoping it will be soon.

Re:Kernel locking

[Kjella]

If you're just doing it for the newer version and don't need to change the code or config it's easier to grab the debs from the Ubuntu Kernel PPA and install.

Re:Kernel locking

[Kjella]

And this is one example of why the kernel doesn't have a stable ABI. You can bet tons of unmaintained third party drivers would use the BKL, so you could never get rid of it. From what I've understood purging it from every driver has been a pretty big job and only possible because all the drivers are in the kernel tree.

Re:Kernel locking

[TheLink]

In terms of performance and everything else that matters, the removal of the BKL has absolutely no impact.

How about reliability and stability? So they've reached the stage where stuff _definitely_ doesn't need the BKL?

Re:Kernel locking

[dsavi]

Actually I believe they will ship with 2.6.38.[1]

Re:Kernel locking

[Anonymous Coward]

already available if you want to install. if you don't know how you probably shouldn't.

Re:Kernel locking

[jimicus]

In Debian Stable - in about 2 years (in the next release).

Doubt it - the next release of Debian Stable can't be that far away, Lenny's starting to look rather long in the tooth and Squeeze was frozen back in August. I'd expect to see Squeeze become stable within the next few months.

Re:Kernel locking

[Carewolf]

Debian is currently packaging 2.6.37RC6, it would give a few weeks and they will have 2.6.37

Re:Kernel locking

[Anonymous Coward]

The BKL hasn't been removed, only turned into a config option. If you turn off the BKL, you also turn off the stuff that still need it.

Much "stuff" was fixed, but not every single driver.

Re:Kernel locking

[pinkeen]

My bad, there were rumours and they were apparently wrong.

Re:Kernel locking

[Karellen]

I think the GP meant "in the next release after Squeeze", which probably will be in about 2 years from now.

Re:Kernel locking

[m50d]

So Linux is going to break the drivers for my webcam, PDA and TV card again? Forgive me if I don't jump for joy. Surely there'd be no harm in having the BKL hanging around - if you don't use any of the old drivers that use it, it'd never get locked and so never delay anything. So not having a stable API (I don't really care about the ABI, but the lack of an API is just atrocious) still looks like laziness from here.

Re:Kernel locking

[Anonymous Coward]

IME Linux has been going downhill since 2.6 started - every release is less stable than the last, which seems a pretty obvious consequence of abandoning the odd-even split they had before. The udev stuff is just insane, I bet there won't be a migration path either - I literally can't set my keyboard layout on linux any more. I wish I could.

LXDE problems are your own fault though; if you want to use something obscure, it's not going to be as well tested or supported as the mainstream options. KDE is plenty configurable, try turning down the effects if they're causing you trouble.

It'll be years before I trust btrfs for anything critical; distros are doing the right thing in not offering it yet. Reiserfs may be old but it's working; to my mind it's the best option on linux. (I've now switched to freebsd for ZFS, which is everything I could want and more). Claiming that FAT is the easiest way to share files with Windows is simply wrong; NTFS pretty much works, and ext2 100% works and, while not great, is much better than fat (e.g. no 4GB filesize limit). And btrfs certainly isn't going to help you with that one.

Re:Kernel locking

[Anonymous Coward]

Here's everyone else's replies summed up in one link after the whole one second of my life it took to look it up (hint: looking things up yourself is incredibly easy and often faster than the time it takes to even ask, let alone wait for replies!)

http://en.wikipedia.org/wiki/Big_Kernel_Lock

Re:Kernel locking

[Anonymous Coward]

The simple solution to that is deprecation for a while, then removal or replacement with a stub (depending on the implications of ignoring or re-interpreting API call). There's NOTHING about having a sane, stable API that means you can't force third parties to keep up. Just the opposite: you can post exactly what's changed in the API on a less frequent basis, making maintainers jobs easier, so they'll be more likely to build stuff and comply with upgrade paths.

Re:Kernel locking

[JackieBrown]

Too bad they rarely build the kbuild package for experiential kernels so that users can actually install the needed kernel header packages.

I don't understand why they even upload them when they are not instable due to dependency conflicts. That said, we are talking about experiential so there is not suppose to be a guarantee that it is installable. It really does feel like a strange effort though since anyone using hardware or software that requires a kernel module to be compiled cannot assist with the testing.

The kbuild package in experimental is for 2.6.36 and I remembering being really surprised that that one was there at the time.

http://packages.debian.org/experimental/linux-kbuild-2.6.36

Re:Kernel locking

[Rysc]

I've rolled my own kernels in Debian since ~potato. It's never been very hard. Just aptitude build-dep your current kernel, cp /boot/config-$(uname -r) to .config in your vanilla source directory and start from there. If you're a bit more fanatical you can get the debian kernel patch set and see about applying that, but I have never bothered and have suffered no ill effects.

Re:Kernel locking

[JackieBrown]

It may be easier, but you miss on on insights and commentary from other users. That is the whole selling point of Slashdot for me since I usually have already read the news somewhere else.

Re:Kernel locking

[Anonymous Coward]

So you have this empty set of people called Nobody, but you manage to make a subset out of it called 'desktop users'.

Re:Kernel locking

[Anonymous Coward]

I'm very much in agreement, but looking something up doesn't in any way at all hinder a person from posting about it and discussing it.

Re:Kernel locking

[Pr0xY]

Certainly ABI changes can be difficult to deal with, but personally I think it is better than keeping old code around like many close sourced systems end up having to do for compatibility purposes.

I've found that a good (not perfect) solution is to write an thin abstraction layer between the module and the kernel. The module pretty much only deals with the kernel through this layer, so if the kernel changes, you have a central place to apply updates (nvidia does this and it has worked very well).

In the end, it's a trade off and you can rest assured that distros will likely build with the BKL enabled for a few releases before phasing it out to avoid compatibility issues.

Re:Kernel locking

[Anonymous Coward]

Its already in Cooker. I'm running the kernel in 2010.2 without issue.

Six Months?

[Anonymous Coward]

Doesn't the .04 mean April?

Re:Six Months?

[Teun]

Ssht, leave some for imagination ;)

Btrfs

[Anonymous Coward]

It's nice to see kernel improvements for Btrfs, but how is Btrfs progressing? It seems like it is constantly under heavy development (completely understandable), but have the guys behind Btrfs released some sort of working version, even if it doesn't do much?

Re:Btrfs

[tibman]

It's running on my server at home, so i hope so ; )

Re:Btrfs

[Anonymous Coward]

I've been using it for nearly 2 years without any issues whatsoever (I haven't even had to fiddle with it to keep it going). It's been in the kernel for over 1 year.

They're well beyond "some sort of working version, even if it doesn't do much". Give it a try.

Re:Btrfs

[tehpola]

Likewise, I just built a new computer and I put two 1TB drives in there and mounted them together as my /home using Btrfs. I haven't played around with it too much yet but so far it's been running buttery smooth. This is under Ubuntu 10.10 with a stock kernel so I'm not exactly at the cutting edge of kernel releases.
Something I haven't worked out yet but was hoping to figure out was getting file cloning working (copy-on-write) in places where I want distinct files (no linking), but don't want to waste storage if I don't wind up changing one.

Re:Btrfs

[0100010001010011]

Before I committed ANY data to ZFS I sure as heck "played around with it" in virtual machines until I was comfortable doing about anything with it.

"Pull" one of the drives. What happens?
dd if=/dev/random of= to your disk in random places (skip/seek), what happens to your data.
Pull all of the drives and replace it with a larger one.

How are the user tools for btrfs? zpool & zfs are fairly well documented and have very simple short commands.

Does it automatically share over nfs/samba like you can with ZFS on Solaris?

Re:Btrfs

[vandy1]

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ has the answer: cp --reflink=always ... You will need a non-ancient version of coreutils for this to work. Cheers, Michael

Re:Btrfs

[Korin43]

The problem with Btrfs isn't that it doesn't work (it works fine and has for years). The problem is that it's not very fast right now (most benchmarks I've seen show it slightly behind other major file systems in most tasks), and most things don't make use of the cool things it does.

Re:Btrfs

[tehpola]

I see what you mean, but this is just a personal computer. I wouldn't be using this in any sort of production systems (nor am an IT guy).

What appealed to me about using Btrfs was that I could dynamically add more disks as I was inclined to upgrade, I could get data striping, snapshots, data deduplication (not implemented yet though), and since I was planning on running Linux, there was no practical solution for using ZFS. The fact that I couldn't pull the drive or that corruption might take things down doesn't concern me too much because if I wasn't using Btrfs I'd be using Ext4 and I wouldn't imagine it would be any better.

The documentation could probably use a little fleshing out, but in the little I've done (very little) setting things up, it was pretty straight-forward. As I said, I have two drives in my pool. When I installed Ubuntu, I only selected one for /home as Btrfs and then later added the second and rebalanced. Both adding and balancing were two simple commands (that I can't remember off the top of my head but were something like 'btrfs add' and 'btrfs balance')

I don't know about any automatic sharing, though, sorry. I'm sure it'd be pretty simple to set it up, but it might not be optimized for those cases.

Re:Btrfs

[glwtta]

The fact that I couldn't pull the drive or that corruption might take things down doesn't concern me too much because if I wasn't using Btrfs I'd be using Ext4 and I wouldn't imagine it would be any better.

Corruption-wise Ext4 better as hell be better than Btrfs, since it was released as stable over two years ago.

Re:Btrfs

[Rich0]

The problem with btrfs is that it is unstable and feature incomplete, and doesn't even have an fsck yet.

I've even gotten it to panic with loopback devices, ext3 conversions, and mirroring.

BTW, I define unstable as lots of patches in every kernel release. It just is very new for any real production work.

It is probably good enough for casual use on straight partitions without use of its more exotic features. I would keep good backups though.

Re:Btrfs

[loxosceles]

Compared to zfs, which is the only other quasi-mainstream filesystem that has copy-on-write (which gives snapshots for free) and data checksums, btrfs is almost always faster. Most of btrfs's slowness is due to those two features. Comparing ext4 speed to btrfs speed is not fair unless you disable both with -o nodatacow.

http://www.phoronix.com/scan.php?page=article&item=btrfs_zfs_ssd&num=1
see page 4 for btrfs random write performance, which blows away both zfs and ext4 on hdds.

Without COW and checksumming, btrfs is closer to ext4. Even so, except for applications that are reading or writing massive amounts of data, I'd rather have data integrity and SSD wear leveling and free read-only snapshots instead of maximum speed.

Re:Btrfs

[KiloByte]

You want cp --reflink=auto instead, so it works even if you issue the command across filesystems or on non-btrfs. There's no reason not to plop alias cp='cp --reflink=auto' into your .bashrc.

Re:Btrfs

[profplump]

You could just turn on LVM, which has been stable (and even the stock config in some distros) for years now and gives you dynamic volume allocation, data striping and snapshots with any filesystem. There are reasons to like ZFS/btrfs/etc., but the things you're asking for are easily available with much older, better-supported, better-documented solutions.

Re:Btrfs

[Adam Jorgensen]

Another problem is the fact that it has very poor crash recovery options. I losted a whole home partition thanks to the BTRFS getting corrupted on some level or other due to a power outage during as read operation, of all things. Not cool.

Re:Btrfs

[TheLink]

see page 4 for btrfs random write performance, which blows away both zfs and ext4 on hdds.

I'd rather have data integrity and SSD wear leveling and free read-only snapshots instead of maximum speed.

1) There are SSDs with decent random write performance now.
2) Shouldn't the SSD wear leveling be done by the SSDs themselves?

Re:Btrfs

[Anonymous Coward]

-o nodatacow

Just out of curiosity, what does a data cow look like?

Still some BKL in kernel

[Dennis Sheil]

This is my understanding of this as well. The Big Kernel Lock has not been completely removed from the kernel, however, it is now possible to choose a kernel configuration option that will compile a kernel without the BKL. This necessitates a BKL-disabled kernel not being able to use some of the modules which still depend on the BKL. However, none of the core modules depend on the BKL any more, and kernel developers are still working on removing the BKL from the handful of less important modules which depend on the BKL.

Ceph is really cool

[Lemming Mark]

Ceph is a really cool bit of technology. It distributes storage redundantly across multiple machines, so you can store lots and lots of data and not lose any if one of the hard drives explodes. It should distribute the load of serving that data too. You can have a network filesystem based on this already, now they've added support for virtual block devices (i.e. remote disks) over it.

If you combine that with virtualisation (the Kernel Newbies changelog mentions that there's a patch for Qemu to directly use a Ceph-based block device) then you can do magic stuff. e.g. run all your services in virtual machines with their storage hosted by Ceph. Provide a cluster of virtualisation hosts to run those VMs. If a physical box needs maintenance, live-migrate your VMs off it without stopping them, then just yoink it from the cluster - the storage will failover magically. If a physical box explodes, just boot the VMs it was running on other nodes (or, combined with some of the hot-standby features that Xen, VMware, etc have started to offer, the VMs are already running seamlessly elsewhere as soon as the primary dies). If you need more storage or more processing, add more machines to the cluster, get Ceph to balance the storage and move some VMs around.

Not everyone is going to want to run Ceph on their home network but if you have a need for any of this sort of functionality (or even just an enthusiasm for it) then it's super cool. Oh yes and Ceph can do snapshotting as well, I believe. Ace.

Re:Ceph is really cool

[Anonymous Coward]

that sounds like a lot of work to look after for a home network....
i wonder if it ever goes wrong ...

Re:Ceph is really cool

[loxosceles]

Not as much work as dealing with traditional RAID arrays. I end up having to RMA and/or replace a few disks a year, and while software raid keeps me from losing data in almost every case, it's a PITA. I'd much rather have that stuff managed automatically by a distributed filesystem. The next external disk enclosure I build is going to be part of a ceph filesystem or something similar. Then I'll reformat my recently built external 6TB raid-6 array and add those to the unified (e.g. ceph) filesystem as well.

In the last year and a half (all of these are SATA, none more than 3 years old):

- An older seagate in my windows box had its power connector catch fire.
- A 1TB WD green drive started failing SMART self-tests soon after installation.
- The other 1TB WD green drive (twin of the one that failed) has a few offline uncorrectables, but I'm not in the mood to replace it yet.
- Both of a pair of 1.5TB seagates (7200.10) are on the fritz; the controller returns errors and resets one or the other every few hours - neither drive gets kicked out of the raid array, but it freezes disk access to the array for 10-20 seconds which has been extremely aggravating. I'm in the process (slowly) of moving data from them onto a newly built external 6TB raid-6 array.
- One of a pair of new 1TB WD blacks in my (several month old) main workstation last week started making horrific scraping noises and failing SMART checks. (I'm replicating that raid-1 array to a third replacement disk as I type this, and then the broken one is getting RMA'd).

It's too much management overhead to deal with these failures piecemeal. The future for large low-maintenance storage arrays is to use something like ceph or Isilon's (commercial) OneFS to automatically manage redundancy to avoid data loss, while allowing full use of disks of any size.

Re:Ceph is really cool

[Anonymous Coward]

The quickest I've ever had a drive fail was in a hardware mirror (1+1) where 1 drive failed while I was installing the OS for the first time. All new hardware! So yeah, you never know when a drive is going to fail.

What's new

[Troll-Under-D'Bridge]

The link in the story just points to the list post announcing a new major version of the Linux kernel. Note that the changes listed in the post are for changes from the last release candidate (-rc8) and not from the last major kernel release (2.6.36). For an overview, it's better to head over to Kernel Newbies. It even has a section which summarizes the "cool stuff", major features that the new kernel brings.

Interestingly, the overview appears to overlook what I believe is a major feature introduced in 2.6.37: power management for USB 3. I may have to do some more digging through the actual kernel changelogs. Maybe the change was reverted during the last few candidate releases, but I remember reading about it in H-Online, particularly this part:

The XHCI driver for USB 3.0 controllers now offers power management support (1, 2, 3, 4); this makes it possible to suspend and resume without temporarily having to unload the driver.

(In the original, the parenthetical numbers are links to the kernel commits.)

Power management for USB 3 would have been the most important new feature for me. Without it, you have to resort to a number of ugly hacks to hibernate or suspend a laptop or a motherboard with USB 3 enabled. (Turning off USB 3 in the BIOS is a hardware hack that allows you to bypass the software hacks.)

Ooops

[Troll-Under-D'Bridge]

I missed the second link in the story, which does point to Kernel Newbies. (Blame it on my browser which doesn't color links in red or some other obscene color.) However, my comment about USB 3 still stands. I'm still trying to find a "news" source that highlights the new XHCI power management feature. Failure to hibernate/suspend because of non-working USB 3 power management is an issue that's been discussed in a number of forums.

Includes the "magic 200-line" task grouping patch?

[sagaciousb]

Looking through the changelog I couldn't find anything immediately evident about whether or not the "200-line kernel patch which does wonders" was included in this release or not. Here is the related original post. Anybody know if it will be in there for certain? I may have to remove my Ubuntu alternative workaround outlined in the subsequent article before doing an upgrade.

Re:Includes the "magic 200-line" task grouping pat

[sciencewatcher]

That patch is scheduled for 2.6.38. This article details 2.6.37. This article is about the end of the pipeline, the article you linked to is about the beginning of the pipeline that kernel development is.

Gurus: will this affect high-SMP workstations?

[isolationism]

I have dual-processor Xeon with six cores each, meaning there are effectively 24 threads (2 physical * 6 cores * 2 hyperthreading) and the system will lock up for SECONDS at a time during large IO operations. The file system is XFS over an 8-disc hardware RAID10 on 15K RPM drives. Seems to be most noticeable when copying to/from the network, although I'm not convinced the network is the problem here. For such a high-end machine these stalls are unbearable; I had (a lot) less difficulty with only 4 cores and less/slower drives in a hardware RAID 0.

Re:Gurus: will this affect high-SMP workstations?

[Anonymous Coward]

Are you starting your IO operations from the console? If yes, there's one major fix in 2.6.37 that could help in your scenario: http://marc.info/?l=linux-kernel&m=128979084506774&w=2

Re:Gurus: will this affect high-SMP workstations?

[Anonymous Coward]

I will assume you're using a software RAID? Try a hardware RAID controller. The buffering alone will solve your problem, not to mention the dedicated processor doing the disk I/O.

Re:Gurus: will this affect high-SMP workstations?

[drinkypoo]

Unless it's a very expensive controller, performance will go down. OTOH, XFS has shown itself to be a bit of a bear... and problem-ridden. I just had it eat my superblock. Took more than an hour for xfs_repair to find the backup. Onward to ext4!

Re:Gurus: will this affect high-SMP workstations?

[Anonymous Coward]

I remember seeing a bug report about poor performance with large amounts of RAM. Ie, in the 32 GB range. Having allot of IO in one thread would block IO in other threads, even if the IO was on a separate ... channel or whatever it is called. Sorry, I'm not a guru :)

So bro, how much ram you got?

Re:Gurus: will this affect high-SMP workstations?

[Billly Gates]

I have never admin-ed SGI machines with XFS admittedly, but from what I was told XFS can never be stable on x86 architecture.

During a power loss a normal machine will have corrupted ram contents before turning completely off. There are protections built into the filesystem like exts or UFS journaling that undue partial transactions. XFS is much faster because it is in real time and doess less integrity work. SGI have power capicitators to correctly finish a write during a powerless. They are very nice machines and XFS was built around nice controllers with expensive hardware that can do the things like I mentioned. Unless x86 hardware does the same sorts of things it will always be less reliable when running XFS.

Re:Gurus: will this affect high-SMP workstations?

[drinkypoo]

That defeats the whole fucking purpose of a journaling filesystem, which should do the right thing in the case of hardware failure (barring SOME TYPES OF disk failure.) That basically means XFS is shit.

Re:Gurus: will this affect high-SMP workstations?

[isolationism]

Yes, I do all of my larger copy operations via terminal window instead of a file manager in X, although I honestly didn't think there'd be much difference. I'm not sure if "smoothness" is really so much the case as outright stalling though; if I didn't know it was coming back I'd have thought my machine has crashed. Thanks for taking the time to reply -- I will check it out once things cool down with work and decide for myself.

Re:Gurus: will this affect high-SMP workstations?

[isolationism]

No -- as stated in my original post, it is a hardware RAID controller. Specifically, it is a 3ware 9690SA (SAS/SATA) model; the drives are all enterprise-grade Seagate SAS2 models.

It's not what I would quantify as a "very expensive" controller (it ballparks around $500 USD), but it's definitely dedicated hardware with cache write-through and other "performance" options enabled.

Re:Gurus: will this affect high-SMP workstations?

[isolationism]

As stated in another post above, it's a 3ware 9690SA -- Not a very expensive controller but not a piece of crap either -- I would expect that this thing is well-travelled enough that it wouldn't perform so bad as to freeze the system for seconds at a time during high io ops.

As for XFS, I'm sorry for your pain -- I've run XFS on 5 workstation and server RAIDs for years and never had anything close to as many problems as I've had with this (relatively new) machine. I've never once had any superblock corruption problems, but admittedly the risk exists -- I keep the computers on a UPS and have BBU's on the RAID controllers themselves as a last resort and have kept out of trouble despite increasingly frequent brownouts and 15+ minute power outages around here. Knock on wood.

Re:Gurus: will this affect high-SMP workstations?

[isolationism]

Hmmm ... that could be related, but I'm "only" at 24GB of RAM, not all the way up to 32. Any idea what I should search for to find if this might be my problem?

Re:Gurus: will this affect high-SMP workstations?

[drinkypoo]

I ran XFS for years too, I was using it as root before such a thing was fashionable, but if I'd had any idea how fault-intolerant it is I would never have used it at all.

Re:Gurus: will this affect high-SMP workstations?

[Anonymous Coward]

OK- kind of dumb question: Do you have the 3ware battery module installed? Something about the write cache won't work without it...

Re:Gurus: will this affect high-SMP workstations?

[isolationism]

Yes, I have a BBU (battery back-up unit) installed, and have the write cache enabled and "Performance" mode set for the "StorSave" profile.

I don't think 3ware actually prevents you from setting it without a BBU installed anyway, but they certainly don't recommend it for obvious reasons. In any case, write cache performance isn't the bottleneck. It seems to be -- strange as it sounds -- something to do with the combination of high disk IO and high network IO.

PPP in ipv4?

[B5_geek]

So, does this mean I don't need to play around with rp-pppoe or pppoe-conf (or equivalent) for DSL setup/configuration? And if yes, how then?

Re:PPP in ipv4?

[ESD]

Unfortunately not. PPPoE runs the PPP protocol over Ethernet, not over an IPv4 connection (which in turn usually runs over Ethernet)
This will probably be more useful for creating tunnels between different IPv4-connected hosts, such as for VPNs.

IO issues

[Sami Lehtinen]

Fuse-NTFS-3G makes my system really crawl when there is USB-disk IO. UI and everything else is totally stalled for long periods. I'm not Linux guru, but I just confirm that I'm also expering IO issues even when system load should be pretty low. "Linux Bender 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 GNU/Linux". I guess some tweaking might be required to fix this issue.

ANOTHER version?

[Anonymous Coward]

Geez... it's a shame Lunis and the boyz couldn't be bothered to program it correctly the first time around.

task groups patch

[Anonymous Coward]

Did Mike Galbraith's per-TTY task groups patch make it? I can't find any reference to it in the release notes.

Re:But...

[Anonymous Coward]

Now you know why your mom's phone was busy when you tried to call.

Versioning?

[fuzza]

So, what's the deal here - have they pretty much abandoned the old "odd minor releases for development, no new features in stable versions" plan, or what?

Re:Versioning?

[shish]

Yeah, they abandoned that a few years ago, current plan is something along the lines of "six weeks development, two weeks bugfixes-only, release, repeat", incrementing the third part of the version number each time (ie there are no plans for the "2.6" part to ever change AFAIK)

The Big Nasty IO Bug

[zx2c4]

You're probably running into this long standing IO bug, which despite complaints for many years, has still not been properly diagnosed. A big mystery, evidently.

Re:The Big Nasty IO Bug

[isolationism]

Argh.

I'd love to volunteer my hardware to help, but by the length of the bug it sounds like they probably already have plenty of people with a variety of hardware willing to run diagnostics -- and the addition of one machine sounds unlikely to solve something that's been ongoing for three years running, now.

Re:The Big Nasty IO Bug

[zx2c4]

Actually, I don't think so. If you're decent at bisecting and can find a reproducible test case, you'd probably be able to help quite a bit. There's been a lot of noise with too little refined testing on this bug. And it appears like there might be multiple things affecting it, on different types of hardware, etc. Basically, the current diagnostic seems like a mess. So by all means, dig in and start debugging.

Not enough information

[Sits]

You don't say which kernel you are using so it could be the problem you are seeing has been fixed by a previous kernel. However it is unlikely the removal of the BKL will make a difference to you if you're using 2.6.36 since most subsystems were already using fine grained locks of their own before this. There might be another different change in 2.6.37 that helps but I'd say its unlikely...

Re:Not enough information

[isolationism]

Linux mars 2.6.36-gentoo-r6 #1 SMP PREEMPT Sun Jan 2 15:46:06 EST 2011 x86_64 Intel(R) Xeon(R) CPU X5670 @ 2.93GHz GenuineIntel GNU/Linux

I am indeed using 2.6.36, and I'm using the "patchless" alternative cgroups approach (which involves creating some new nodes and stuffing a few lines into ~/.bashrc. I was thinking it was less likely that the BKL would make a difference and hoping maybe some of the other things mentioned in the article would make a difference, like the cgroup io-throttling integration and SMP scalability improvements to XFS -- although I guess it depends whether the scalability refers to the size of the array (which is quite small, only 1TB) or the processor threads (which is quite large, at 24).

Pretty bad design to begin with then

[Anonymous Coward]

Pretty bad design to begin with then, if drivers have direct access to internal kernel locks. What you are saying is that you don't want stable ABIs, because then you would not be able to do shoddy job after shoddy job without having to own up.

Kinda like how the whole USB subsystem was turned inside out and upside down 3 times in a row, doing a complete overhaul because the previous one sucked so bad that it was broken beyond redemption.

Re:Pretty bad design to begin with then

[Kjella]

Pretty bad design to begin with then, if drivers have direct access to internal kernel locks.

A driver could not possibly function without a means to lock and unlock kernel resources. That you obviously have no idea what you're talking about shows you're only trolling.

Re:Pretty bad design to begin with then

[samjam]

What you want is for someone to code it just how you want, first time and no-rewrites. Only this post said it better: http://linux.slashdot.org/comments.pl?sid=1937200&cid=34772938

Only... the coders get to chose how to code it (are you one?) and they learn as they do it, so next time is always better...

I guess they didn't want to wait 10 years while they coded without BKL and so did a quick release with BKL to get the benefits of SMP. They could have took the otehr road, but you would have complained then as well - or if you hadn't, someone else would have,

Re:Pretty bad design to begin with then

[Anonymous Coward]

Actually I have written device drivers both on linux and Windows (XP and 2003). USB and PCI drivers to be precise.

External locks (like the BKL) 'should' be manipulated only via an API. Not directly. And it 'should' only be used by device drivers for those external scenarios. And in that case, it should not matter for the driver whether they get 'a' KL or the BKL.

Drivers accessing the BKL directly is a bad design decision, and could have been avoided.

You mention that the lock is needed to access resources. I say that a) if a lock was needed, it could have been returned by an API instead of accessed directly, in which case it could have been replaced under the cover, and b) resource specific locking should have been done via a resource specific API where possible, instead of defaulting to the BKL or accessing a lock directly.

How many times have people argued that global variables are bad? They are bad in kernel design as well, for the same reason that they are avoided in application design.

Re:Pretty bad design to begin with then

[Anonymous Coward]

You really have no idea what you're talking about. BLK isn't "bad" for the same reason that global variables are bad - and comparing the two shows just how little you know about both topics. Global variables are bad because you run into really obscure problems related to variable scope and you begin stepping on other variables. BLK is bad because it's basically incredibly lazy and has a very negative performance impact. Trying to equate those two things is really stupid.

Ah, the bloated monlithic kernel

[DrSkwid]

Requiring all sort of synchronisation and a release cycle. Plan9 has a release *every day*.

Re:Btrfs & ZFS

[Anonymous Coward]

you got to be kidding me! BTRFS will take years to reach where ZFS is now. Super fast performance is not an FS is all about. Reliability, scalable performance and ease of use are the primary goals for a good FS. BTRFS doesn't have a fsck. What good are checksums if you never gonna be using them? It chokes with ENOSPC (yes, try 2.6.37, the latest stable code) when it has 39% free space. Create large number of small files and small number of large files, PANIC! It has no dedup! Learn about ZFS when you have time. Its really as good as its purported/hyped to be.