kjournald2 writes to disk about every 10 seconds

[deew]

Every few seconds the disk writes (or reads - i have no idea).
iotop shows it to be kjournald2. kjournald2 only shows up in system monitor if it is launched with sudo.
Karmic beta i386 on intel atom mini-itx

[Jarlen (jesper-jarlskov)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we can't fix it because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures

At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
4. the system you use, ie. which version of (K)Ubuntu & kjournald2
Thanks!

[deew (dee-wykoff)]

1. the specific steps or actions you took that caused you to encounter the problem,
     I looked at the the computer.
2. the behavior you expected, and
     I expected the hard drive light to stay off unless I was running a program or doing something.
3. the behavior you actually encountered (in as much detail as possible).
     As I mentioned: "Every few seconds the disk writes (or reads - i have no idea)." And also: "iotop shows it to be kjournald2. kjournald2 only shows up in system monitor if it is launched with sudo."
4. the system you use, ie. which version of (K)Ubuntu & kjournald2
Thanks!
     As I mentioned: "Karmic beta i386 on intel atom mini-itx"

I am in agreement that the bug report does not contain much info. It is like that because I have no idea what other info someone might want. If you need more info then please tell me what other info you need. I am looking for something along the lines of "Please type blah-blah at the command line and post the output." I am well aware of my own shortcomings as a bug figure-outer, I simply noticed a bug and reported it in the hopes that the bug will be fixed while my hard is still good.

Thanks.

[Richard Guo (rfguo)]

This is either a really serious problem that's being overlooked or something very silly wrt the configuration of some programs.

I'll try to describe this bug as it appears for me. Let me know if you require more information.

I'm running kubuntu 9.10 64 bit testing with the latest updates as of posting (installed from daily images). This problem manifests itself at all times, starting from boot. In essence, kjournald2 is making periodic writes to the hard drive, somewhere in /, not in /home (as I've got that on a different partition).

Not only does this result in frequent wakeups of the hard drive, but it also consumes disk space!

Attached is the evidence. iotop shows the culprit, and df shows my disk space gradually dwindling with every second.

For further information, my uname -a is Linux aiur 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

I'm using ext4 on all partitions and have noatime set as a flag. There are no processes running that I am aware of that hook into kjournald2 to cause writes.

[Richard Guo (rfguo)]

Here is iotop.

[Richard Guo (rfguo)]

Okay, I did more investigation and something definitely isn't right here. My desktop is running the same OS with latest updates; the only difference is that it was upgraded from jaunty instead of a fresh install. On there, I can go idle for hours without any difference in my df free space.

On my laptop, df decreases by 8 bytes every half second or so, as with the attachment.
The surprising thing is that it appears to be the very act of doing a df that causes the free space to go down by 4-16 bytes each time, no matter how long I wait. This of course varies because there is actual logging going on.

I also tried to find out which files were being modified; my suspicions were the logs. Many of the most recently touched files were /proc, but excluding those, I couldn't find anything meaningful. There were /tmp and .mozilla stuff that looked correct.

Very frustrating bug, if that.

[Richard Guo (rfguo)]

Another smoking gun here.

I did echo 1 > /proc/sys/vm/block_dump and then dmesg. There were huge differences between my laptop and my desktop. On the desktop, the only active disk writes on idle were dirtying of inodes, specifically by rsyslogd and plasma-desktop. These, as you can expect, don't change free disk space. On the laptop, kjournald2 was responsible for WRITE block commands. This I believe means the allocation of new blocks, which explains why i'm constantly losing free space.

Attached is the relevant dmesg for my laptop.

[Richard Guo (rfguo)]

As I suspected, the free space usage does not decrease with a reboot, meaning that the written-to space is not in /proc or /tmp. This is very strange then, since the find results indicate that no file is being written to rapidly, but the block_dump indicates that some blocks (not inodes) are being written to.

It seems to point to a kernel bug that spams WRITEs to contiguous free blocks but not storing any meaningful files to those locations.

[deew (dee-wykoff)]

Richard,
     Thanks for adding all the info. Apparently they deemed the original report a little sparse. Maybe this will help.

[Richard Guo (rfguo)]

Okay, I've resolved the issue of df showing decreased space with each iteration. It turns out that konsole was saving the scrollback history to /tmp. Disabling that solved that particular problem.

kjournald2 is still writing every so often to disk. I assume that this is just updating dirty inodes caused by the running WM. I guess this bug should be marked as invalid or not fixing.

[lianergoist (tj001)]

Does any of you with this problem use the wifi-driver ath5k? I don't know why, but if I stop wifi (by disable wifi in network-manager, by switching off the wifi-card in my netbook, or by running "modprobe -r ath5k) the harddisk led stop lighting up every 5 to 15 seconds.

I ran iotop in 5 minutes with wifi disabled, and this is the output:

14:23:50 370 be/3 root 0.00 B 8.00 K 0.00 % 0.00 % [kjournald2]
14:23:51 623 be/3 root 0.00 B 4.00 K 0.00 % 0.00 % [kjournald2]
14:23:51 3005 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:24:25 623 be/3 root 0.00 B 16.00 K 0.00 % 0.00 % [kjournald2]
14:24:27 3005 be/4 root 0.00 B 8.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq

Then I turned on wifi and ran iotop again i 5 minutes:

14:30:16 370 be/3 root 0.00 B 28.00 K 0.00 % 0.00 % [kjournald2]
14:30:16 3007 be/4 syslog 0.00 B 4.00 K 0.00 % 0.00 % rsyslogd -c4
14:30:17 623 be/3 root 0.00 B 28.00 K 0.00 % 0.00 % [kjournald2]
14:30:17 3043 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:30:26 3007 be/4 syslog 0.00 B 12.00 K 0.00 % 0.00 % rsyslogd -c4
14:30:32 623 be/3 root 0.00 B 32.00 K 0.00 % 0.00 % [kjournald2]
14:30:40 370 be/3 root 0.00 B 56.00 K 0.00 % 0.00 % [kjournald2]
14:30:45 623 be/3 root 0.00 B 40.00 K 0.00 % 0.00 % [kjournald2]
14:30:46 3043 be/4 root 0.00 B 8.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:30:56 3007 be/4 syslog 0.00 B 20.00 K 0.00 % 0.00 % rsyslogd -c4
14:30:57 3043 be/4 root 0.00 B 12.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:30:58 3043 be/4 root 0.00 B 16.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:31:56 3007 be/4 syslog 0.00 B 28.00 K 0.00 % 0.00 % rsyslogd -c4
14:31:57 3043 be/4 root 0.00 B 20.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:32:00 370 be/3 root 0.00 B 60.00 K 0.00 % 0.00 % [kjournald2]
14:32:01 623 be/3 root 0.00 B 44.00 K 0.00 % 0.00 % [kjournald2]
14:32:03 3043 be/4 root 0.00 B 24.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:32:54 623 be/3 root 0.00 B 88.00 K 0.00 % 0.00 % [kjournald2]
14:32:54 1313 be/4 thomas 0.00 B 12.00 K 0.00 % 0.00 % gconfd-2
14:32:55 3043 be/4 root 0.00 B 28.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:32:58 623 be/3 root 0.00 B 116.00 K 0.00 % 0.00 % [kjournald2]
14:32:59 3043 be/4 root 0.00 B 32.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:33:21 370 be/3 root 0.00 B 64.00 K 0.00 % 0.00 % [kjournald2]
14:35:01 370 be/3 root 0.00 B 68.00 K 0.00 % 0.00 % [kjournald2]
14:35:02 3043 be/4 root 0.00 B 36.00 K 0.00 % 0.00 % python /usr/bin/iotop -n 300 -obat -qqq
14:35:07 623 be/3 root 0.00 B 120...

[Lindomar Oliveira (lindomaroliveira)]

This is really very frustrating. I'm using an Acer Aspire One 8GB SSD and recently installed Karmic. I've noticed this frequent disk write because It appears to lock chromium until the write is off. It makes the computer a bit laggy compared to Jaunty.

I wonder if this is because of Ext4...

Will try removing the driver ath5k as stated above and watch for changes...

[deew (dee-wykoff)]

I also have wifi running. The card is a: http://www.newegg.com/Product/Product.aspx?Item=N82E16833315041v EDIMAX EW-7128G.
I just tried disabling wifi and that did not make it stop (the hard drive light keeps flashing).

[Lindomar Oliveira (lindomaroliveira)]

So... I've tried a lot of alternatives to enable writeback on ext4 disabling journaling and kjournald. After all I've give up and reinstalled karmic using ext2.

What a wonder !! Now AAO is pretty fast.

Definitely Karmic + ext4 isn't the best choice to netbooks with SSD. At least until this problem with kjournald2 is solved.

[Ralf (ralf-weyer)]

I'm experiencing the same problem on my Kubuntu 9.10 installation on a Samsung E-152 notebook.

What I'd like to know, are there any news on this, will there be fix available in the future? Otherwise I'm really considering a reinstallation of Kubuntu 9.10 and using Ext3 instead of Ext4.

Regards, Ralf

[deew (dee-wykoff)]

Ralf, Not sure if anyone that does "bug fixing" is still looking at this. I think Jarlen (see 1st post) may have "blackballed" this bug because of lack of info. I may have kinda sorta posted a smart @$$ reply (see 2nd post) and worsened the situation. So, it may be best if someone would just file a fresh bug report with more info than the original. In the meantime, be content in the knowledge that hard drives are becoming more affordable.