jbd2 process (ext4 journal) is writing on disk all the time

mkkot · 2011-07-13 09:45:52

Okay, some mad people yesterday took my bike, locked me in the house and made me eat 4 kinds of home-made pizza. Nevermind, here I am trying to compile this kernel. Lars, thanks a lot for preparing this package. Maybe you could explain what the hell went wrong after 1,5h of compilation:

(done from user account)
$ cd kernel26-x201
$ makepkg
...
[compilation]
....
INSTALL /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/whiteheat.fw
MKDIR /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/keyspan_pda/
INSTALL /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/keyspan_pda/keyspan_pda.fw
INSTALL /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/keyspan_pda/xircom_pgs.fw
MKDIR /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/cpia2/
INSTALL /home/mk/kernel26-x201/pkg/kernel26-x201/lib/firmware/cpia2/stv0672_vp4.bin
DEPMOD 2.6.39-x201

==> Cleaning...
-> Cleaning other files...
-> Compressing man and info pages...
==> Creating package...
-> Generating .PKGINFO file...
-> Adding install file...
-> Compressing package...
==> Starting package_kernel26-headers()
chown: wrong user: `root.root'
==> ERROR: Error occured in package_kernel26-headers().
Aborting...

When I do from user account chown root.root /home/mk/some_file, it shows the same. But doc says makepkg should be run from user account, so...?

As I read, this should make 2 kinds of kernel, 32 and 64 bit, right? What I'm trying to do is to prepare a 32 bit kernel for my laptop on a 64 bit PC (it's way faster on the PC). And I need a failsafe vmlinuz image so this junk laptop hardware boots at all. I want to install on my PC a 64 bit kernel to do tests as well. Maybe it is possible to resume makepkg process? Thanks!

Last edited by mkkot (2011-07-13 09:48:04)

Lars Stokholm · 2011-07-13 11:32:34

Hmm, it works here.

[root@x201 ~]# chown root.root file 
[root@x201 ~]# chown lars.users file 
[root@x201 ~]#

[lars@x201 ~]$ chown root.root file
chown: changing ownership of `file': Operation not permitted

Anyway, I think a colon is the right way to go. Just fix it in PKGBUILD:

chown -R root:root ${pkgdir}/usr/src/linux-${_kernver}

And it only builds a package for your architecture, afaik.

Edit: http://www.google.com/search?q=chown+dot+colon

Last edited by Lars Stokholm (2011-07-13 11:37:19)

slytux · 2011-07-13 14:31:59

You don't need to redo the headers and build the docs, just the kernel, change the '$pkgname' line in the PKGBUILD to have:

 pkgname=('kernel26')

It should be building for the architecture detected which is probably 32-bit. Do not try to cross-compile, build on an x86_64 box if you need 64-bit.

You can make the second kernel alongside the stock Arch one to have in case something goes wrong. Let's call it "kernel26-debug" In the PKGBUILD change the name and change the line that starts with 'package_kernel26() {'

 pkgname=('kernel26-debug')

 package_kernel26-debug() {

Add it to your grub:

# (2) Arch Linux
title  Arch Linux -debug
root   (hd0,0)
kernel /boot/vmlinuz26-debug root=/dev/sd* ro
initrd /boot/kernel26-debug.img

slytux · 2011-07-13 14:41:07

I see you are using Lar's PKGBUILD. He did not comment line 5 and did not change the name of line 116, that's why it's messed up. He called his 'kernel26-x201' but there can only be one $pkgname line. See instructions above.

Last edited by slytux (2011-07-13 14:43:40)

mkkot · 2011-07-13 14:52:11

Okay, thanks, I'll look into it. Now I'm trying to figure out what is wrong with my chown: https://bbs.archlinux.org/viewtopic.php?id=122509

slytux · 2011-07-13 14:59:33

So it seems to be from syslog-ng then. My home desktop with the SSD has logs going to RAM since I have /var/log mounted as tmpfs so even if something were writing every 5 secs, it wouldn't be hitting the disk.

 tmpfs   /var/log        tmpfs   noatime,defaults,size=512M,mode=1777 0 0

Also, in syslog-ng, you can use the "flags(final);" which keeps matching logs from being written to subsequent log files. This way, cron's logs can be kept in /var/log/crond.log and won't show up in /var/log/everything.log

 log { source(src); filter(f_cron); destination(d_cron); flags(final); };

They will still show up in auth.log because that line is above it (unless you move it).

mkkot · 2011-07-14 17:07:20

Made an update for the bug: https://bugzilla.kernel.org/show_bug.cgi?id=39072
Conclusion: there is nothing wrong with ext4.

agon · 2011-07-22 17:55:42

After having posted in an quite old thread about this problem (and necrbumped it, which leaded to closing it. Sorry) I found this one.

jdb2 does write to disk every minute or so, althought I use atime and commit=600, making it impossible for mi HDD to spin down and stay that way. I've mounted tmp, /var/lock and /var/run as /tmpfs and also moved with a script /var/log and /var/tmp and my firefox and macromedia stuff to ram.

Currentrly, my daemons look like this:
DAEMONS=(syslog-ng vartmp @acpid @laptop-init @laptop-mode !network @networkmanager !netfs !wicd !crond @alsa !gopreload @preload)

Could the diska ctivity be caused by preload? How would it show up in iotop? By the way, my iotop reveals that sometimes jbd2 gets active just after upowerd or NetworkManager do. Could one of these be te culprit?

Last edited by agon (2011-07-22 17:58:12)

cemsbr · 2011-09-08 16:38:46

I found the culprit, at least in my case, and it is byobu. If you don't use byobu, try quitting screen instead. I'm trying to use tmux as byobu backend, but it uses screen regardless of what is written in /etc/byobu/backend.

y4mz · 2012-03-02 20:06:25

I am encountering frequent disk access on an up to date, very minimal Arch installation, as well as GParted Live (0.12.0) on the same hardware.

It happens when newly formatted ext4 partitions are mounted, and stops (for good) after a period of time proportional to the size of the partition.

For example, after being mounted, a 200 GiB partition is accessed roughly twice a second for around 10 minutes. This then stops and never happens again.

I found this doesn't occur with partitions formatted without the 'uninit_bg' option.

It's not a problem but I'm curious about what's happening.

stopspam · 2012-03-05 00:36:55

I'm experiencing same issue whereas i only use ext3 partition ! jbd2 process start each time another one (cron, syslog-ng...) is running, so every 3 or 5 seconds. The system is slow. It seems that ext3 was journaling by jbd (first version) and now (since kernel 3.0) it's jbd2.

After downgrading to kernel 2.6.39.3-1 (last good one for me), everything become normal !

Any idea ?

falconindy · 2012-03-05 01:54:44

stopspam wrote:

I'm experiencing same issue whereas i only use ext3 partition ! jbd2 process start each time another one (cron, syslog-ng...) is running, so every 3 or 5 seconds. The system is slow. It seems that ext3 was journaling by jbd (first version) and now (since kernel 3.0) it's jbd2.
After downgrading to kernel 2.6.39.3-1 (last good one for me), everything become normal !
Any idea ?

No, jbd2 has always been used for ext4. More likely is that we've enabled CONFIG_EXT4_USE_FOR_EXT23 meaning that jbd2 is now used for ext2 and ext3. Sounds like something you should file a kernel bug about.

stopspam · 2012-03-05 20:08:36

CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4_USE_FOR_EXT23=n
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=m

I've compiled the last 3.2.8 with theses options. ext3 module is back. So jbd !
Any explanation for a such change in arch kernel ?

Last edited by stopspam (2012-03-05 20:09:11)

fax8 · 2012-03-05 20:23:53

I'm also experiencing the slow system problem with jdb2 eating all the io and cpu resources. I'm not sure how should I fix this?

linas · 2012-07-28 23:03:49

y4mz wrote:

I am encountering frequent disk access on an up to date, very minimal Arch installation, as well as GParted Live (0.12.0) on the same hardware.
It happens when newly formatted ext4 partitions are mounted, and stops (for good) after a period of time proportional to the size of the partition.
For example, after being mounted, a 200 GiB partition is accessed roughly twice a second for around 10 minutes. This then stops and never happens again.
I found this doesn't occur with partitions formatted without the 'uninit_bg' option.
It's not a problem but I'm curious about what's happening.

You pretty much nailed it with the mantion to uninit_bg. What you are seeing is the lazy_itable_init option. Instead of preparing all the inodes at mkfs time, it is done afterwards during use.

From man 8 mkfs.ext4:

lazy_itable_init[= <0 to disable, 1 to enable>]
If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds
up filesystem initialization noticeably, but it requires the kernel to finish initializing the filesystem in the back‐
ground when the filesystem is first mounted. If the option value is omitted, it defaults to 1 to enable lazy inode ta‐
ble zeroing.

JohnLudos · 2012-10-14 09:26:05

mkkot wrote:

Okay, case closed. This doesn't allow drive spin-down but it's another thing to improve in system's configuration, I think. Anyway, here's a solution:
mount
Find your ext4 partition. If you found something like:
/dev/sdx on / type ext4 (rw,noatime,commit=300,commit=0)
then read further. ...

And what if

ludos@ludos:~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
gvfs-fuse-daemon on /home/ludos/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ludos)

?
I've got the same problem: process jdb2/sda1-8 is writing on disk, and I can't fix it.

mkkot · 2012-10-14 10:19:05

Then your default commit value (5 s.) is used I guess. You can try to increase it or look for a culprit, kernel bugzilla already linked here might be helpful: https://bugzilla.kernel.org/show_bug.cgi?id=39072

JohnLudos · 2012-10-15 13:21:24

Thanks mkkot,
regrettably I can't fix the problem in any of the proposed senses...
Since a while my hdd also started to ticking. I'm doing many back ups, but is wery frustrating to be unable to do anything.

P.S: Could be a good idea (not elegant I know) to change ubuntu version? It started to run that command since the upgrade to Ubuntu 12.04 precise pangolin with Gnome classic interface.
Anyone has idea of a different version I could try?

Last edited by JohnLudos (2012-10-15 13:37:39)

mkkot · 2012-10-16 18:30:36

Why won't you ask on Ubuntu forum? We don't know ubuntu's distribution-specific problems here. Maybe it's file indexing? Or maybe you wish to check your HDD with smartctl.

uros09 · 2014-04-03 15:19:25

Gentoo Comunity has answer on your questions:

The problem turned out to be the combination of RAID and the barrier option on ext4. It seems to cause some kind of race condition during heavy writing scenarios. I've been mounting that filesystem with "-o barrier=0" for months with no further problems. The consensus seems to be that barriers are a nice thing to have but not critical - they were only added relatively recently and aren't even available with all hardware. So I feel relatively safe about avoiding it at least until the bug is fixed.

This solved problem and I calm down writing which goes up to 99% jbd2/md0-8.... on iotop :
mount -o defaults,noatime,commit=60,barrier=0,remount /dev/md0 /
after that writing is 2%

You are welcome

ewaller · 2014-04-03 15:48:24

uros09,
Welcome to Arch Linux. Thank you for am informative first post, but be careful of old threads
I've not seen some of the participants in this thread for a long time. You are right, though. Gentoo forums are a tremendous Linux resource.

I am going to go ahead and close this thread now,

Arch Linux

#51 2011-07-13 09:45:52

Re: jbd2 process (ext4 journal) is writing on disk all the time

#52 2011-07-13 11:32:34

Re: jbd2 process (ext4 journal) is writing on disk all the time

#53 2011-07-13 14:31:59

Re: jbd2 process (ext4 journal) is writing on disk all the time

#54 2011-07-13 14:41:07

Re: jbd2 process (ext4 journal) is writing on disk all the time

#55 2011-07-13 14:52:11

Re: jbd2 process (ext4 journal) is writing on disk all the time

#56 2011-07-13 14:59:33

Re: jbd2 process (ext4 journal) is writing on disk all the time

#57 2011-07-14 17:07:20

Re: jbd2 process (ext4 journal) is writing on disk all the time

#58 2011-07-22 17:55:42

Re: jbd2 process (ext4 journal) is writing on disk all the time

#59 2011-09-08 16:38:46

Re: jbd2 process (ext4 journal) is writing on disk all the time

#60 2012-03-02 20:06:25

Re: jbd2 process (ext4 journal) is writing on disk all the time

#61 2012-03-05 00:36:55

Re: jbd2 process (ext4 journal) is writing on disk all the time

#62 2012-03-05 01:54:44

Re: jbd2 process (ext4 journal) is writing on disk all the time

#63 2012-03-05 20:08:36

Re: jbd2 process (ext4 journal) is writing on disk all the time

#64 2012-03-05 20:23:53

Re: jbd2 process (ext4 journal) is writing on disk all the time

#65 2012-07-28 23:03:49

Re: jbd2 process (ext4 journal) is writing on disk all the time

#66 2012-10-14 09:26:05

Re: jbd2 process (ext4 journal) is writing on disk all the time

#67 2012-10-14 10:19:05

Re: jbd2 process (ext4 journal) is writing on disk all the time

#68 2012-10-15 13:21:24

Re: jbd2 process (ext4 journal) is writing on disk all the time

#69 2012-10-16 18:30:36

Re: jbd2 process (ext4 journal) is writing on disk all the time

#70 2014-04-03 15:19:25

Re: jbd2 process (ext4 journal) is writing on disk all the time

#71 2014-04-03 15:48:24

Re: jbd2 process (ext4 journal) is writing on disk all the time

Board footer