<linux-2.6.30_rc6-r5 & reiserfs: don't do it - 2.6.33 UPDATE

[kernelOfTruth]

when using reiserfs, reiser4, etc.

and if you DON'T need updated access time information

use the following options:

[Chewi]

Just a heads up for you guys. I noticed this in the announcement for 2.6.31-rc7 from Linus. I'm not sure which version introduced this problem, it may have just been one of the earlier release candidates.

[genstorm]

For those of you still having important reiserfs partitions, it might be a good idea to avoid moving on to 2.6.33 too fast. At least wait until after the first 2.6.33 final version when it has already seen broad adoption.

There's currently a lot of work going on to kill the BKL (at least) in reiserfs:

[kernelOfTruth]

[pappy_mcfae]

Boy howdy, it sure is a good thing kernel.org is still supporting the .27 family. .31 and .32 have been experiences in broken, as far as I'm concerned. Now, they're going to break things even more? Doesn't seem like a smart way to do business.

BB!
P
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.bloodnoc.org/
Mirror 2: http://kernel-seeds.audiodef.com/
Mirror 3: http://www.elilabs.com/~pappy/

[kernelOfTruth]

since there's no intermediate "stable" kernel releases between a kernel release and another (or does the uneven number .33 equals unstable ?)
there unfortunately doesn't seem to be another way ...

you're right - it's not the best way to do such updates (if data integrity potentially could suffer) ...


fortunately it wasn't that bad for me (yet) - but there were / are a lot of more bug-reports on the reiserfs mailing-list with nullpointer, etc. exceptions


lets just hope they'll iron out most of those bugs or all and migrate to another filesystem on some of our partitions
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004

[devsk]

[pappy_mcfae]

Sometimes life on the bleeding edge can be incredibly dangerous to Linux machines. Personally, I wish they'd take the time to fix more so than to make the "new and exciting". But that's not the ruling paradigm, or so it seems from the outside.

Oh well, I ran on 2.6.29-zen2 for almost six months before another personally acceptable kernel version came out. Personally acceptable means it doesn't break my setup, or if it does, the fix is easy, and won't involve something as important as my main file system. With this news on .33, I'm getting the feeling I might just be stopped at the last .30 and .31 version zen kernels until someone fixes all these "improvements".

BB!
P
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.bloodnoc.org/
Mirror 2: http://kernel-seeds.audiodef.com/
Mirror 3: http://www.elilabs.com/~pappy/

[cyrillic]

[Dont Panic]

Since I didn't have a clue what BKL stood for, and why it's important to reiserfs, I Googled a few sources to explain the issue to myself.

BKL stands for "Big Kernel Lock". Reiserfs makes considerable use of this function. Apparently this function has been in the Linux kernel for years (basically since it was rebuilt for SMP), but, as it's name implies, BKL usage can cause latency issues.

Here is some background links on efforts to "Kill the BKL":

"kill the Big Kernel Lock (BKL)" tree

Kill BKL Vol. 2

Here's a link an the efforts to remove the BKL from reiserfs.

reiserfs: kill-the-BKL

The patch referenced in the previous article was released in April of 2009, so the effort has been proceeding for many months.

Here's a link on the request to Linus to pull this patch into the 2.6.33 kernel.

[GIT PULL] reiserfs/kill-bkl for 2.6.33

[pappy_mcfae]

Dont Panic,

Thanks for the info. Interesting stuff, if they can make it work. I'll just have to make sure I do stage4's all around before I go there.

Blessed be!
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.bloodnoc.org/
Mirror 2: http://kernel-seeds.audiodef.com/
Mirror 3: http://www.elilabs.com/~pappy/

[genstorm]

I couldn't help but jump the gun with 2.6.33_rc3-git5. No problems so far with reiserfs or any other part of the kernel, but time will tell.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

[kernelOfTruth]

[genstorm]

Yes, I read that and Linus hoped to have it all fixed by now. Anyway, I was growing tired of 'backporting' that huge amount of i915/drm changes, thinkpad-acpi and ralink updates I immediately wanted to have...

So far it's (it currently being rc4-r1) a really stable experience, I've had rc6 kernels giving more trouble. Only some new dib0800 lib wouldn't let dib0700_devices.c compile. Also, dmesg is quiet.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

[cyrillic]

So far so good.

I am running 2.6.33-rc4 on a couple of machines, and I have not noticed any reiserfs related problems.

[pappy_mcfae]

Have you noticed this supposed speed increase yet?

BB!
P
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.bloodnoc.org/
Mirror 2: http://kernel-seeds.audiodef.com/
Mirror 3: http://www.elilabs.com/~pappy/

[genstorm]

Well, this isn't based on any hard evidence, but I feel that desktop responsitivity isn't down on its knees anymore during hefty IO workloads. That was really, really bad and I always blamed CFS for it, but BFS didn't really make it much better. Now it feels a lot multitaskier, more suitable to a dualcore system. Of course, this could also be due to massive scheduler improvements in the kernel, but none of them ever helped in the past.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic