jbd2 writing block every 5 - 10 seconds, preventing disk spin-down and making noise

A 1 minute log was generated using the following commands...

sudo -i
echo 1 > /proc/sys/vm/block_dump # Start logging
# Wait 1 minute
echo 0 > /proc/sys/vm/block_dump # Stop logging
exit

Results from /var/log/kern.log are attached. Noise/write occurs at jbd2 entries e.g....
Jul 20 00:15:35 edge kernel: [ 7281.741214] jbd2/sda5-8(347): WRITE block 68124096 on sda5

i have the same problem:

* OS: Gentoo
* Disk fomat: ext4
* Kernel: 2.6.32

so it is not ubuntu specific, arch users have this problem also. maybe this info helps solving it.
first thing i'll try is upgrading kernel.

Hi rCX,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

This problem seems to have been resolved in the latest mainline kernel 2.6.35-999-generic_2.6.35-999.201007211008. jbd2 only writes every 1-2 minutes which is more tolerable. Unfortunately, I had to downgrade back to 2.6.32-23-generic-pae because of another bug.

rCX, I'm not sure I'd call every 1-2 minutes tolerable, though it is certainly better. Why does there need to be any excess disk activity at all? On a netbook install, 1-2 minutes will still prevent the system from going to sleep automatically because the disk activity fools the system into thinking it's not idle. Besides, its loud.

Is there a mechanism to disable this process or is it required if journaling is used? Why doesn't ext3 have this behavior? It's also a journaling filesystem, right?

Matthew Holtz, I guess you're right, this would still be a problem on netbooks. Hopefully someone will mark this as confirmed.

I've been playing around with different settings. Adding commit=60, to the partition's entry in fstab increases the interval to 30-45 seconds. No solution yet.

What hard disk are you using? I have a Fujitsu MJA2250B.

I am also experiencing this behavior on an eeePC 1000. It appears that is affecting the sleep when idle functionality as it won't sleep when I set it to 10 min on A/C power.

I'm having the same problem on Debian testing/unstable:

Linux 2.6.32-5-686 #1 SMP Wed Aug 25 14:28:12 UTC 2010 i686 GNU/Linux

Is there any progress about this?

The 2.6.35 kernel for Debian is currently in experimental and I don't know where will it be upgraded to unstable.

How can I stop my disks from spinning? I have LVM and, for luck, half of my disks are free. Should I migrate my partitions to ext3?

As I understand it we can either wait for a new kernel or change away from ext4.

On Fri, Sep 10, 2010 at 8:32 PM, Jaime Alberto Silva
<email address hidden> wrote:
> I'm having the same problem on Debian testing/unstable:
>
> Linux 2.6.32-5-686 #1 SMP Wed Aug 25 14:28:12 UTC 2010 i686 GNU/Linux
>
> Is there any progress about this?
>
> The 2.6.35 kernel for Debian is currently in experimental and I don't
> know where will it be upgraded to unstable.
>
> How can I stop my disks from spinning? I have LVM and, for luck, half of
> my disks are free. Should I  migrate my partitions to ext3?
>
> --
> jbd2 writing block every 5 - 10 seconds, preventing disk spin-down and making noise
> https://bugs.launchpad.net/bugs/607560
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “linux” package in Ubuntu: New
>
> Bug description:
> jbd2 writes blocks to the hard disk every 5 seconds.  This makes an annoying click/tick noise and prevents the disk from spinning down to conserve power.  jbd2 appears in logs as several entries like...
>
>  Jul 19 21:35:45 edge kernel: [ 3312.913759] jbd2/sda5-8(350): WRITE block 42280704 on sda5
>
> ... and can be observed using iotop. Since the noise only occurs in Ubuntu and not in Windows 7 it is probably a software problem.  The excessive writes may reduce the disk's lifespan.
>
> Other info...
> * OS: Ubuntu 10.04 LTS
> * Disk fomat: ext4
> * Kernel: 2.6.32-23-generic-pae
>
> Threads covering this problem
> * http://ubuntuforums.org/showthread.php?t=1489637
> * https://bbs.archlinux.org/viewtopic.php?pid=692073
>
> ProblemType: Bug
> DistroRelease: Ubuntu 10.04
> Package: linux-image-2.6.32-23-generic-pae 2.6.32-23.37
> Regression: No
> Reproducible: No
> ProcVersionSignature: Ubuntu 2.6.32-23.37-generic-pae 2.6.32.15+drm33.5
> Uname: Linux 2.6.32-23-generic-pae i686
> AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
> Architecture: i386
> ArecordDevices:
>  **** List of CAPTURE Hardware Devices ****
>  card 0: Intel [HDA Intel], device 0: ALC269 Analog [ALC269 Analog]
>    Subdevices: 1/1
>    Subdevice #0: subdevice #0
> AudioDevicesInUse:
>  USER        PID ACCESS COMMAND
>  /dev/snd/controlC0:  rcx      2456 F.... pulseaudio
> CRDA: Error: [Errno 2] No such file or directory
> Card0.Amixer.info:
>  Card hw:0 'Intel'/'HDA Intel at 0xf0800000 irq 22'
>    Mixer name   : 'Intel G45 DEVIBX'
>    Components   : 'HDA:10ec0269,17aa21bc,00100004 HDA:80862804,80860101,00100000'
>    Controls      : 16
>    Simple ctrls  : 8
> Date: Mon Jul 19 23:24:03 2010
> Frequency: Every 5-10 seconds.
> HibernationDevice: RESUME=UUID=ae276af8-b805-466a-a688-8d175cd3f2d7
> InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
> MachineType: LENOVO 05782AU
> ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-23-generic-pae root=UUID=01d19f79-8c81-4da6-949d-db8f4d85b84a ro quiet splash
> ProcEnviron:
>  SHELL=/bin/bash
>  LANG=en_US.utf8
> RelatedPackageVersions: linux-firmware 1.34.1
> SourcePackage: linux
> dmi.bios.date: 06/11/2010
> dmi.bios.vendor: LENOVO
> dmi.bios.version: 80ET37WW (1.14 )
> dmi.board.name: 05782AU
> dmi.board.vendor: LENOVO
>...

Seems to be the ext4 journaling doing its thing. You can increase the interval (in seconds) by adding for example

  commit=60

to mount-options in /etc/fstab, or disable it altogether with

  tune2fs -O ^has_journal /dev/sda5
  e2fsck -f /dev/sda5

(or whatever your disk is called). Your disk will be more vulnerable for data corruption on uncontrolled shut-downs without journaling.

I understand that ext4 does journaling and that the journal must be
written to disk from time to time. What escapes me is why the disk
must be written every few seconds __when no disk access is needed at
all__.

That is the issue I struggle with on my netbook -- most of the time I
need no disk access when browsing the internet, yet my disk accesses
every 5 to 10 seconds like clockwork.

That is why this is a bug.

this wasn't a problem in early releases of Ubuntu 10.10 kernel. Now that we are in RC, it is back and it is a bad thing to have as it kills battery life. I will get on IRC and see if i can get some traction on this.

cat /proc/mount yields a mount commit=60 (that is too fast). Any how, iotop clearly shows jbd2 constantly flushing preventing the hard drive from spinning down.

this is a real issue that we should fix for 10.10

After much investigation, i discovered that the output of "hdparm -B /dev/sda" happen to be my only laptop hard drisk, gives me a value of 128, which permits the HD from spinning down. This is what is prevents the hard driver from spinning down and not the jbd2 activity. BTW, I did a complete fresh install.

from hdparm man page (notice the bit about 128 being in the range that prevents spinning down):

   -B Query/set Advanced Power Management feature, if the drive sup‐
              ports it. A low value means aggressive power management and a
              high value means better performance. Possible settings range
              from values 1 through 127 (which permit spin-down), and values
              128 through 254 (which do not permit spin-down). The highest
              degree of power management is attained with a setting of 1, and
              the highest I/O performance with a setting of 254. A value of
              255 tells hdparm to disable Advanced Power Management altogether
              on the drive (not all drives support disabling it, but most do).

Anmar,

That is interesting. I'll have to try it on my netbook and see what it reports. However, I maintain that I should not have to change this, particularly on a netbook install. The default should be to spin the drive down to save power, especially if that power mode is selected from the Gnome power manager.

I wrote a new bug since I don't think this is a jbd2 issue at all. You can find the details here: 654561

I tried using hdparm to set this parameter down to 1. This had no effect on my netbook, and the jdb2 process was still doing the disk writes every 5 seconds or so. I don't agree with your assessment that this is not a jdb2 issue.

Same problem here after upgrading to 10.10 yesterday. I doubted that hdparm would be a proper fix and actually it didn't show any effect.

I am having the same issue, but I dont think its a spin down issue. I am using laptop-tools and the disk wakes up every 2 mins due to the flush. The disk is really spinning down (the JBD2 writes seems to be getting cached by laptop mode), but the flush is waking up the drive. someone here https://bbs.archlinux.org/viewtopic.php?id=105456 seems to think that the flush is being cause by the frequent JBD2 writes, though I am certain if this is the case or not.

This also affects me.

Sometime jbd2 just freeze my laptop for 5 minutes. CPU usage is mostly sy(stem) in "top" output. Look the attached screenshot.

This also affects me. I think this must be a bug somewhere in 10.10.

Sometime jbd2 just freeze my laptop for 5 minutes. CPU usage is mostly sy(stem) in "top" output. Look the attached screenshot.

Affects me as well .. I am not on a laptop and have the latest daily kernel build.

Same problem here using Mandriva 2010.1, kernel linux 2.6.33.7-desktop586-2mnb on usb flash drive w/ ext4 partitions. jbd2 continues to hammer on my flash drive. Disabling rsyslogd did stop the numerous log writes but jbd2 continues on. Switched away from ubuntu because I thought it was ubuntu flavor that was burning up my flash drive. Guess I was wrong.

I just built a minimal ubuntu system, albeit there are a few background services running. I'm seeing jbd2 disk access in iotop. Its happening every between 30 seconds, up to 2 min. Maybe we just need a better way to find out what processes are causing the disk activity.

I'm thinking that there is something that is another process causing the writes, but its not getting shown by iotop.

This affect me too. jbd2 appears in iotop every five ir six seconds.

Add me to the list, jbd2 is accessing IO every few seconds. I'm considering rebuilding my system as ext3 instead.

This is affecting me too! jbd2 is accessing IO every 2 seconds. Please fix this problem before my hard drive gets damaged!!!

I am using ubuntu 10.10 64bit

I am experiencing this problem with Ubuntu, Debian, and Fedora. It seems to be a kernel bug that is affecting every distro. Best to avoid ext4 until this is resolved. Otherwise your laptop hard drive will get worn out in short order by the frequent spin cycles.

This problem seems to be occurring on Arch as well. There is a thread about it here [url]https://bbs.archlinux.org/viewtopic.php?id=113516[/url], which links to a kernel patch that may solve the issue:
[url=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e44718318004a5618d1dfe2d080e2862532d8e5f]jbd2: call __jbd2_log_start_commit with j_state_lock write locked[/url]

I just reinstalled on a ext3 partition, and the same issue occurs. The only difference is instead of jbd2 writing every few seconds, it is kjournald. Both are 64 bit systems.

In reference to #31, I am seeing the same thing on ext3 partitions in multiple distros and systems, 32-bit and 64-bit. With ext4, jdb2 continually accesses the disk when the laptop is otherwise idle. With ext3, kjournald does the same thing, maybe slightly less frequently.

Also affected...I noticed that began after an upgrade of the kernel, I think it's the 2.6.32.28-generic I686

-Laptop
-ubuntu 10.04 LTS (openbox & gnome)
- 2.6.32.28-generic I686
- ext4
- /dev/sda8 / ext4 errors=remount-ro 0 1
- /dev/sda5 /home ext4 defaults 0 2
- /dev/sda6 none swap sw 0 0

kubuntu 10.04 64 bit, harddrive light flashes every second.
- Linux server 2.6.32-29-generic #58-Ubuntu SMP Fri Feb 11 20:52:10 UTC 2011 x86_64 GNU/Linux

want to add that after installing ubuntu to a different harddrive the problem no longer occurs.

Harddrive that experienced issue: Seagate 1TB 7200rpm drive.
New that doesnt: 1TB SAMGSUNG 7200rpm

I'm also using a Seagate 1TB 7200rpm drive (ST31000528AS) having this problem.
(I used a Western Digital drive before that and didn't have this problem - but that was about 2 years ago...)

Seagate 1TB here - the same problem.

Same problem here.

Ubuntu 10.10 64 bit / 2.6.35-28-generic
Disk one, Seagate barracuda 500 gig - ext4 - sda3 on /
Disk two, Samsung spinpoint 500 gig - ext4 - sdb1 on /home

I tried booting into the recovery mode with the shell and networking.
After a few seconds nothing, no jdb2. No disk activity at all running iotop.

This is the only time jdb2 did not access the disks.

After this I followed these instructions and on my system it worked:
~~~~~~~~~~~~~
We can confirm that our ext4 partition is running a journal with: (where X is the partition number, sda1,2,3,4 etc)

$sudo dumpe2fs /dev/sdaX | grep has_journal

Disabling journaling is rather easy, the only drag is that to make structural changes to a filesystem, the filesystem cannot be mounted with read/write privileges. So, run a live cd, open a terminal and enter:

$sudo tune2fs -O ^has_journal /dev/sdaX

And it's done. Now when you boot, the change will be noted and the disk will be checked for errors. When the system is finally up we can run this again to confirm that in fact ext4 is running without a journal.

$sudo dumpe2fs /dev/sdaX | grep has_journal

should now return nothing.

With this quick fix, no more constant IO peaks.
~~~~~~~~~~~~~

The tune2fs man page has this entry about 'has_journal'.

-O [^]feature[,...]

Set or clear the indicated filesystem features (options) in the filesystem. More than one filesystem feature can be cleared or set by separating features with commas. Filesystem features prefixed with a caret character ('^') will be cleared in the filesystem's superblock; filesystem features without a prefix character or prefixed with a plus character ('+') will be added to the filesystem.

The following filesystem features can be set or cleared using tune2fs:

has_journal
Use a journal to ensure filesystem consistency even across unclean shutdowns. Setting the filesystem feature is equivalent to using the -j option.

Lol guys, what the frack is this:)? I've just found this bug (if it's bug) on my PC. I have latest Ubuntu 11.04, kernel 2.6.38 and jbd2 makes constantly IO every 2 seconds. Heh... I may wander why my disk is crazy as hell and had to changed it.

I recently had a Seagate SATA 300+gig drive fail. Since it was in warranty I sent it in and apparently it was affected by bad firmware that Seagate had updated for that drive. However there' no real way to check if your drive needs a firmware update unless you contact them. My drive was sent to data recovery for free (because it was in warranty) with the determination that it was totally unrecoverable because the drive had essentially self destructed. Way to much particulate matter the destroyed the platters.

Since there seems to be a pattern with Seagate.. I'd check to see if the firmware needs updating. No idea if this will fix the problem or not that everyone is experiencing. When my drive started failing I would notice excessive writes and system slowdowns up to the point where it would spin/access continuously. This was on a 3.5" drive desktop mounted.

I am having this issue with a fakeraid

May 9 16:27:41 kernel: [ 1340.660185] flush-252:2(1158): WRITE block 137365408 on dm-2 (8 sectors)
May 9 16:27:41 kernel: [ 1339.971524] sync_supers(21): WRITE block 16760 on dm-2 (8 sectors)
May 9 16:27:39 kernel: [ 1338.132441] jbd2/dm-3-8(21399): WRITE block 1854150760 on dm-3 (8 sectors)

2 hd of 1TB Model=ST31000524AS
it occur on a new ubuntu naty install

If I disable journaling it stop with jbd2 errors but The 'sync_supers' keep on, the thread wakes up every 5 seconds and writes back all super blocks. It keeps waking up even if there are no dirty super-blocks, annoyingest bug ever, Do I need change the distro again? I had no problem with this on gentoo stable that's using kernel 2.7*

Mmmm on my /var/log/kern.log
after
echo 1 > /proc/sys/vm/block_dump # Start logging
# Wait 1 minute
echo 0 > /proc/sys/vm/block_dump # Stop logging
i have
May 11 11:36:31 hal-9000 kernel: [ 6997.824107] jbd2/sda3-8(248): WRITE block 13017328 on sda3 (8 sectors)
May 11 11:36:37 hal-9000 kernel: [ 7003.808089] jbd2/sda3-8(248): WRITE block 13017328 on sda3 (8 sectors)
May 11 11:36:43 hal-9000 kernel: [ 7009.824112] jbd2/sda3-8(248): WRITE block 13017328 on sda3 (8 sectors)
ecc...

Linux Mint Debian Rolling Release (alias debian testing)
$ uname -ar
Linux xxxxxx.xxxxxxxx.com 2.6.38-2-amd64 #1 SMP Thu Apr 7 04:28:07 UTC 2011 x86_64 GNU/Linux

attach my /var/log/kern.log

it can be the same bug??

ByezZz

Same problem here. and I used 'iotop -oPa' as diagnose tool.
Machine 1:
Xubuntu 11.04 64-bit, reiserfs, jfs and xfs

Machine 2:
Ubuntu 11.04 32-bit, ext4fs.

I'm doing more investigation and this problem (with me) might be directly related to jfs.

With xfs mounted (2 days non-stop):

   10 be/4 root 0.00 B 466.57 M 0.00 % 0.03 % [sync_supers]
  948 be/4 root 788.00 K 133.77 M 0.00 % 0.01 % [jfsCommit]

With xfs umounted (about 18 hours):

   10 be/4 root 0.00 B 189.60 M 0.00 % 0.01 % [sync_supers]
  948 be/4 root 20.00 K 38.88 M 0.00 % 0.01 % [jfsCommit]

I think I can achieve more accurated results with 'time iotop -oPa'. I'll try again with jfs umounted to see.
Also I'm collecting more data from friends (uname -a, time iotop -oPa, mount, all together).

I'm here again. I did some tests with xfs and jfs umounted here (only reiserfs up) and things didn't change too much. For now, I just made a new setup here in sysctl. Anyone here with rock-solid machines and ups can do the same.

Create a file under this path:

$ editor /etc/sysctl.d/60-vm.dirty_writeback_centisecs.conf

Inside, you can set another time (default is 500 centiseconds, which is 5 seconds between each wake up). In my case, I'm doing now with 1500 centiseconds.

vm.dirty_writeback_centisecs=1500

Put a blank line after the line above, save and exit. Then you can make thing working ASAP without rebooting:

$ sudo sysctl -w vm.dirty_writeback_centisecs=1500

The file above is just to preserve your settings between reboots.

SIDENOTE: notebook users, this is just a workaround. It won't prevent your hard disks from waking up.

After some days testing several configs to see which one could achieve a better result towards sync_supers' anger, I think I've found a good workaround. I'm testing it since 2011-04-28 and so far it's working pretty well:

vm.dirty_ratio=60
vm.dirty_writeback_centisecs=15000

Please check also if the value below is already a default:

vm.dirty_background_ratio=5

This is a good setup for a desktop, but it might be a painful one for a busy server. If you want to test or even make your changes permanent, please read my comment (#46) above.

The above recommendations have no impact with the issue on my system.

time settings will not solve this jornaling ext4 issue, that you could get ride of this by removing jornaling from it but it's not a good idea at all.
this is the most annoying bug ever, that I have presenced, the hd noises won't stop until you turn of the pc or maybe change the SO that's seems a great choice.
sorry but.. ext4 sucks a lot no matter what anyone try to prove against, and the sad thing is that there is no secure filesystem that you can rely your /home files if not ext4.

I just came back - after a painful migration - from btrfs which, at the time, sucks even much more (extreme slugishness with many applications, continuous activity too and no fsck).

Are we still left with ext3 or XFS for a decent FS?

I have this bug on 2 machines, both running Lucid and ext4, one is 32, one is 64 bit.
Harddisk light every second!
I tried disabling journalling with tune2fs but it did not do a thing.

This is crazy.

The same on Ubuntu 11.10 (Oneiric Ocelot, BETA).
I can't sleep at night because HDD LED is flashing and flashing... and flashing!
Every 3-5 seconds, like a torture with droping water.

I has this problem as well. I was able to resolve the problem (or at lease significantly reduce the issue of jbd2 writes as reported in iotop) by mounting my /tmp, /var/tmp, and my /var/log into a tmpfs in fstab. I believe /var/log is the culprit. After mounting var/log (although it is possible it is /tmp or /var/tmp - I didn't test each individually) to tmpfs at boot (via fstab), the problem goes away. I assume the "writes" are still occurring, but are being written to RAM rather than to disk.

If the above is true, the problem is likely related to logging. I would be interested to hear someone else trying the above "solution" to see if the problem is resolved.

example lines from my fstab:

tmp /tmp tmpfs rw,nosuid,nodev,noexec,noatime,mode=1777,size=1024k 0 0
vartmp /var/tmp tmpfs rw,nosuid,nodev,noexec,noatime,mode=1777,size=1024k 0 0
varlog /var/log tmpfs rw,nosuid,nodev,noexec,noatime,mode=0755,size=8192k 0 0

I basically did the same as John ^ - but I used Ramlog (http://www.tremende.com/ramlog/index.htm) - it basically mounts your /var/log as ramdisk and synchronizes the contents when you shut down / start your computer with /var/log.hdd. Playing around with "iotop -oPa" I was able to find some more apps which continuously wrote to my harddisk. This page also helped me a lot: http://info4admins.com/tips-to-spindown-your-hard-disk-in-debian-or-ubuntu/

Hi,

I wanted to let you know some of my recent experiences. I also had the HDD LED blinking slightly every two seconds and a bit stronger every few seconds on my desktop PC. Previously I had gentoo running with gentoo-kernel 2.6.30-r4 and did not observe anything like this. Then I installed kubuntu-11.10 and saw that blinking. I used "iotop -oPa" and the top entry was relatd to jbd2. I then tried "noatime", different commit times, reinstalled with ext3 or reiserfs, but everywhere the same slight blinking every 2 seconds.
I also tried fedora 15 and 16beta live CDs, nothing changed.
I do not observe this slight blinking, when my PC is in BIOS-Setup or when I boot an old Knoppix (does not run through for compatibility reasons as expected) and again, did not observe it with gentoo-kernel-2.6.30-r4.
This is very annoying as it seems to be unclear what the real source here is (kernel > version XYZ?!, etc.) and if indeed it is actually a bad thing, which I would assume as I don't expect the LED to blink and thus represent an unneccessary activity, particularly when the system is idle.
My system is based on an ASUS P5E (X38 chipset), Intel Q6600 with 2 (fairly new) S-ATA HDDs.

I just found out something quite surprising to me: stopping DBUS also results in a stop of this weak, annoying, heart-beat like blinking!
Naturally, disabling such a central component as DBUS (especially with KDE, as in my case) is not a desirable solution. And I am also wondering why DBUS does not show up in the output of "iotop -oPa"...

I was having this bug in Kubuntu 11.04. It's gone now. Only thing I can think of was I added ibus. I created manual y folders for ibus in home/user/.config/ibus/bus.

I went into Locales and set the default locale to en-us and the input method to ibus-kde. It seemed to clear dozens of problems.

I'm also experiencing this on my 11.10 system. Very annoying for a notebook user.

I also have the problem on 11.10 with a Lenovo T400.

I'm also affected with an Acer D255 on 11.10

Same problem on a Lenovo B570 on 11.10 fully updated.

same problem. Dell Latitude E6400 on Fedora 16 fully updated...

The problem is still present and really annoying. Ubuntu 64 bit 11.10, Kernel 3.2.1, ext4fs with ecryptfs encrypted home folder, Lenovo R400.
As it seems to be related to logging (and maybe DBUS), any chance to solve it?

I have the same problem.

Here my configuration:
Ubuntu 11.10 64bits, Kernel 3.0.0-15
FS ext4

I have the same problem.

"
root@boson:~# uname -a
Linux boson 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
"

"
root@boson:~# hdparm -i /dev/sda

/dev/sda:

 Model=TOSHIBA MK5059GSXP, FwRev=GN001U, SerialNo=31TPC530T
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode
"

I think the problem is explained in here:
https://www.linuxquestions.org/questions/debian-26/why-root-is-remounted-with-commit%3D0-%3D600-specified-in-fstab-at-the-end-of-start-up-923132/

For example:

"
root@boson:~# mount
...
/dev/mapper/tanty-home on /home/tanty type ext4 (rw,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0,commit=0,commit=0,commit=0,commit=600,commit=600,commit=0,commit=0,commit=0)
...
"

As you see, my hard disks have been remounted with the commit parameter once and again. In Ubuntu, this is done by:

"
root@boson:~# dpkg -L pm-utils
...
/usr/lib/pm-utils/power.d/journal-commit
...
"

Basically, it remounts the HD with "commit=0" when in AC power and with commit=600 in BAT power.

I've applied this patch:

"
root@boson:~# cat /usr/lib/pm-utils/power.d/journal-commit.diff
--- /usr/lib/pm-utils/power.d/journal-commit.orig 2012-02-17 10:45:13.302448184 +0200
+++ /usr/lib/pm-utils/power.d/journal-commit 2012-02-17 10:38:49.864546816 +0200
@@ -2,7 +2,7 @@

 . ${PM_FUNCTIONS}

-JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-0}
+JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-60}
 JOURNAL_COMMIT_TIME_BAT=${JOURNAL_COMMIT_TIME_BAT:-600}

 help() {
"

Don't know yet if it is solved. I will report.

To provide some more information on this problem:
1. The time between the writes of jdbd2 is exacttly the 'commit'-mount-parameter of my root-partition. The default is 5 seconds, if I set it to 60 seconds, then the write occurs every 60 seconds.
2. It is only a problem on the root-partition. I got partitions form /home and other things and no write happens on these.

jdb2 itself is imho not the problem: The write is only the effect of another write from another application. This is why some of the reporters were able to remove the periodical writes by uninstalling applications. Perhaps there is even no single application which is problematic but instead multiple.

I have the same problem.

Ubuntu 11.10 64bits (Linux Mint 12)
FS ext4

Same situation here.

Desktop. Xubuntu 11.10, 64bit, kernel 3.0.0-16-generic. Filesystem ext4.

jbd2 writes to disk every ~5sec when there is activity (like web browsing), or every ~20-30sec when idle. Writes mostly in / partition, but occasionally in /home.

I confirm this is also present in Ubuntu 12.04 (beta2) amd64.
Also, constant writes can have negative effect on SSD.

Same problem for me in Ubuntu 12.04 beta2 amd64. It's annoying...

I have the same problem.
Ubuntu: 11.10 64bits (up to date), FS ext4
jbd2 is writing every few secs.
                                        iotop -obtqqq | grep jbd2
18:17:01 905 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.06 % [jbd2/sda2-8]
18:17:03 905 be/3 root 0.00 B/s 7.76 K/s 0.00 % 69.12 % [jbd2/sda2-8]
18:17:05 277 be/3 root 0.00 B/s 31.05 K/s 0.00 % 56.13 % [jbd2/sda1-8]
18:17:11 277 be/3 root 0.00 B/s 0.00 B/s 0.00 % 4.33 % [jbd2/sda1-8]
18:17:11 905 be/3 root 0.00 B/s 3.88 K/s 0.00 % 3.95 % [jbd2/sda2-8]
18:17:12 905 be/3 root 0.00 B/s 3.88 K/s 0.00 % 2.47 % [jbd2/sda2-8]
18:17:17 277 be/3 root 0.00 B/s 0.00 B/s 0.00 % 3.56 % [jbd2/sda1-8]
18:17:17 905 be/3 root 0.00 B/s 3.88 K/s 0.00 % 3.20 % [jbd2/sda2-8]
18:17:23 277 be/3 root 0.00 B/s 0.00 B/s 0.00 % 3.98 % [jbd2/sda1-8]
18:17:26 905 be/3 root 0.00 B/s 3.88 K/s 0.00 % 3.76 % [jbd2/sda2-8]
18:17:29 277 be/3 root 0.00 B/s 7.74 K/s 0.00 % 7.27 % [jbd2/sda1-8]
18:17:32 905 be/3 root 0.00 B/s 34.91 K/s 0.00 % 4.23 % [jbd2/sda2-8]
18:17:34 277 be/3 root 0.00 B/s 0.00 B/s 0.00 % 4.40 % [jbd2/sda1-8]

 Here is my /etc/fstab:
UUID=f5336321-c585-411c-92b8-8ac474cbebb6 / ext4 errors=remount-ro,noatime,commit=60 0 1
UUID=c5f2e2bd-6292-4733-93f6-da9b3ed0ec4e /home ext4 defaults,noatime,commit=60 0 2
UUID=324f9108-1336-48ce-93d6-cbba235cc683 none swap sw 0 0

Any progress on this issue? Thank you for your time and help!

There is something that I don't understand.
As listed above, there are activity on both partitions, root and home.
It seems difficult to know what file is really written by jdb2 process (logs ?), so it's difficult to know for what application or thread those IO are done.
Moreover, we can see some activity that doesn't result in any read or write (0.00 B/s in DISK READ, and 0.00 B/s in DISK WRITE).
So, what does jdb2 at this moment that could looks like an IO for iotop ?
What could explain that jdb2 doesn't respect the commit interval for everyone ?

If someone could made a brief summary of what is known about this jdb2 process, it will be helpful in order to build more tries to isolate the process or the file that takes the most amount of IO.

to draco:
iotop doesn't show all io, though it detects it. For example: there's audible write sound from HDD, iotop (running with -a) doesn't show any change for any of processes but "TOTAL WRITE" field on it's top line quickly flickers with something like 340K/s (you may need to lower update interval to 0.5 sec to see this).

What works best for me is a block_dump. Instructions at the end of the post work for me in Xubuntu 11.10. With this thing I discovered that there's actually quite a lot of processes that do io.
Attached my 15mins of idling (almost). As can be seen there's ranges of times when almost no io (including jbd2) present.

To find filename from inode number you may try this: "find /home -inum 4765696" - not always work.

Also you may use "find /home -cmin -1" to find which files were modified in less than one minute on home partition. For / it'll look something like this "find /bin /dev /etc /home /lib /media /mnt /opt /root /sbin /srv /tmp /usr /var -cmin -1" - add/remove directories as required.

jbd2 doesn't respect the commit interval for everyone most likely because pm-utils remount partitions with changed commit value.
/usr/lib/pm-utils/power.d/journal-commit
JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-0} #will remount partition on AC power with commit=0.

#block_dump
#"leafpad" is a lightweight text editor, should be in ubuntu by default but not sure.
sudo -i #go into root shell
leafpad /etc/rsyslog.conf #comment line starting with "$ModLoad imklog". This will prevent receiving kernel messages by syslog and thus lessen disk activity.
restart rsyslog #restart syslog
mkdir /tmp/mytemp #create temporary directory
mount -t tmpfs -o size=100000000 none /tmp/mytemp #create temporary FS in RAM, roughly 100MB in size.
dmesg -c #empty kernel messages buffer (contains lots of data from boot time)
echo 1 > /proc/sys/vm/block_dump #enable hdd activity dumping.
watch "dmesg -c >> /tmp/mytemp/trace_01.txt" #this dumps hdd trace into trace_01.txt every 2secs. Wait some time... Do something...

echo 0 > /proc/sys/vm/block_dump #disable hdd activity dumping
umount /tmp/mytemp #unmount temporary directory. DON'T FORGET TO COPY TRACE RESULTS!
leafpad /etc/rsyslog.conf #uncomment "#$ModLoad imklog"
restart rsyslog #after restart, hdd activity dump will be in syslog. Basically you can skip creating temporary directory if you don't plan to trace your hdd for too long.
exit #exit from root shell

Ubuntu 12.04 amd64

Linux a975 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

affirmative

Hello all.

Wanted to inform that there's fresh thread in Archlinux forums and associated bug on bugzilla.kernel.org with some debugging instructions:
https://bbs.archlinux.org/viewtopic.php?id=139087 - Intense disk IO (jbd2 and flush) blocks user interface
https://bugzilla.kernel.org/show_bug.cgi?id=42895 - jbd2 makes all system unresponsive

Even if it's not exactly the same bug, still there's someone with jbd2 writing every ~3 secs and he's got his problem solved (or at least now he knows that in his case it was Chrome's activity).

I myself wasn't so lucky. I hear HDD activity but don't see anything extraordinary in ftrace output:
http://paste.ubuntu.com/981398/

Bug report is still open! If you have something to say or ask - it seems to be good time to do it.

Hello.

I made some posts in https://bugzilla.kernel.org/show_bug.cgi?id=42895 and once again it was decided that jbd2 is not to blame. Read explanation given by Jan Kara and Theodore Ts'o at the end.

Overall people from kernel.org have seen my "15 mins of idling" block_dump (see attachment in post 73, above) and consider it normal, so if you have something that looks vaguely similar then just try to configure your apps/system to have fewer writes. Use debugging tools (like block_dump) to determine what applications frequently write to disk.

Some programs which generate periodic writes on Xubuntu 11.10:
NOTE: it's on _my_ system - they may behave differently on yours.

System:
NetworkManager - every 5min writes into "timestamps" file.
xfconfd - every 10min, into "xfce4-panel.xml".

User:
Evince (every ~1min writes your current position in file) - try MuPDF - extremely light weight, fast and to the point; look for key bindings in man pages ("man mupdf"). But guess it reads only pdf.
Firefox (v.11) - constantly writes into places.sqlite (history, bookmarks) and cookies.sqlite databases along with their support files -shm and -wal. Also writes in "sessionstore" and DOM storage (java apps storage; some sites use it aggressively), and that's not counting cache.
Here some of my tweaks:
browser.sessionstore.interval - 15000 -> 120000 #This preference controls how often information about the current session (open tabs, e.t.c.) is saved to the profile. In ms (15000ms=15s).
dom.storage.enabled - true -> false #DOM apps storage (java scripts and apps); if enabled will update database file frequently on some sites. Should not affect browsing experience.
Disable history - Edit -> Preferences -> Privacy -> "Remember my browsing history" - Uncheck #Disables history for good (you can still use "back" and "forward" buttons). Otherwise firefox will write into history database on every url visited + ~every 1min (sometimes even when idle). Use bookmarks instead. Much faster! Noticeable fewer disk usage! (select Edit -> Preferences -> Privacy -> "When using the location bar, suggest:" - "Bookmarks").

Also I moved "mlocate" from "/etc/cron.daily" to backup directory. I prefer to run it manually from time to time (when needed):
sudo /usr/bin/ionice -c3 /usr/bin/updatedb.mlocate
NOTE: "locate" is very useful command if you want to find something quick. "find" will take some time to search whereas "locate" gives you results instantly because it searches in it's database and not on actual filesystem.

Also you may try to change relatime option (used by default) to noatime in fstab (add it at the end of options field, like this "errors=remount-ro,noatime"). It should lessen HDD usage a little. Because as "mount" man page state for relatime option:
... In addition, since Linux 2.6.30, the file's last access time is always updated if it is more than 1 day old ...
I.e. if file.txt atime is 2012.05.17 12:00 then on 2012.05.18 12:01 you can simply click on it in file manager to trigger atime change (and disk write). It's very actual for "find" command since during search it accesses lots of dirs (on average / partition it's more than 10000) and their atime gets ch...

1. block_dump (see post 73). I should mention again that you may skip creating tempfs dir altogether.
2. find (see post 73).
3. ftrace

FTRACE
Note: ftrace should be enabled on most more or less recent systems by default.

Overall usage:
ATTENTION: overall rule - after you have traced whatever you wanted return all values to the state they were in before trace (usually disabled)! Use "cat" to check them beforehand.
1) sudo -i
2) enable required tracer (see below)
3) enable trace:
echo 1 > /sys/kernel/debug/tracing/tracing_on
4) see trace results:
cat /sys/kernel/debug/tracing/trace #Open as usual file.
OR
cat /sys/kernel/debug/tracing/trace_pipe #See trace results in real time. May be piped to file. Stop viewing with Ctrl+C. NOTE: reading from this file consumes its output.
#For example: "cat /sys/kernel/debug/tracing/trace_pipe > /tmp/mytemp/trace_results"
5) disable trace:
echo 0 > /sys/kernel/debug/tracing/tracing_on
6) disable whatever tracer you have used ("echo 0")
7) "exit" from root shell

Tracers:

echo 1 > /sys/kernel/debug/tracing/events/ext4/ext4_mark_inode_dirty/enable #will show how apps dirty inodes (they will be written to disk eventually). ATTENTION: redirect output to file in tmpfs instead of watching it in terminal (because terminal writes to pipe inode or socket when it outputs to the screen thus dirtying it and will just flood your output).

echo 1 > /sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable #try to look if some application uses fsync aggressively thus making system to immediately write data to disk.

Ubuntu 12.04 LTS. This bug affects me as well. Intevalls are pretty irregular.

~$ sudo iotop -obtqqq | grep jbd2:
23:34:46 270 be/3 root 0.00 B/s 0.00 B/s 0.00 % 3.42 % [jbd2/sda7-8]
23:34:50 953 be/3 root 0.00 B/s 3.88 K/s 0.00 % 4.38 % [jbd2/sda8-8]
23:34:57 270 be/3 root 0.00 B/s 15.50 K/s 0.00 % 2.21 % [jbd2/sda7-8]
23:35:08 270 be/3 root 0.00 B/s 7.75 K/s 0.00 % 3.40 % [jbd2/sda7-8]
23:35:29 270 be/3 root 0.00 B/s 0.00 B/s 0.00 % 1.35 % [jbd2/sda7-8]
23:35:38 270 be/3 root 0.00 B/s 19.37 K/s 0.00 % 2.36 % [jbd2/sda7-8]
23:35:49 270 be/3 root 0.00 B/s 7.75 K/s 0.00 % 3.73 % [jbd2/sda7-8]
23:36:09 270 be/3 root 0.00 B/s 0.00 B/s 0.00 % 1.79 % [jbd2/sda7-8]
23:36:22 270 be/3 root 0.00 B/s 15.50 K/s 0.00 % 1.77 % [jbd2/sda7-8]
23:36:29 270 be/3 root 0.00 B/s 7.75 K/s 0.00 % 3.10 % [jbd2/sda7-8]

~$ mount -l:
/dev/sda7 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)
/dev/sda4 on /boot type ext4 (rw)
/dev/sda3 on /media/Share type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096) [Shared]
/dev/sda8 on /home type ext4 (rw)
gvfs-fuse-daemon on /home/ari/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=ari)

Haven't done any advanced debugging yet.

I tried using an fstab option to make ext4 sync its journal data less often, but found that Ubuntu's power management scripts were overriding my change. After a bit of reading and poking around, I created /etc/pm/config.d/10_journal_commit_time containing this line:

JOURNAL_COMMIT_TIME_AC=30

This sets the journal sync interval to 30 seconds when on AC power, which I feel is safe on my system because I'm using a UPS.

After I made this change, stopped my kernel from updating atime on every file access, and rebooted, disk activity settled down to a tolerable rate. It's now more like what I expected based on the applications I use.

I used Eugenel's debugging method nr. 2 (find) and correlated it to the iotop outputs. The attached file includes listings of the recorded hard drive activity both while idling and while having Google Chrome open.

I think I may have identified the culprit in my case. What's common to all entries is hard drive writing activity in "/dev/ati/card0". if you look at the last intervall (15:25:30-15:26:40) you'll find that it's the only recorded change. Thus we can assume that most of the jbd2 I/O activity in the previous intervalls can be attributed to the same location.

Two questions:

1.) Any idea why I can't access "/home/ari/.gvfs" despite being in a root shell?

2.) Does anyone know what "/dev/ati/card0" is used for? Can't open the file with gedit.

Thank you in advance.

Confirmed for me too on ubuntu 12.04 3.2.0-32-generic #51-Ubuntu SMP x86_64

/usr/lib/pm-utils/power.d/journal-commit is gone but the problem is still here and very annoying:

# iotop -obtqqq | grep jbd2
03:37:23 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 99.99 % [jbd2/dm-1-8]
03:37:24 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 16.55 % [jbd2/dm-1-8]
03:37:29 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.18 % [jbd2/dm-1-8]
03:37:30 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 9.47 % [jbd2/dm-1-8]
03:37:35 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 5.70 % [jbd2/dm-1-8]
03:37:41 401 be/3 root 0.00 B/s 0.00 B/s 0.00 % 5.56 % [jbd2/dm-1-8]

# uname -a
Linux flax 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal

The disk also doesn't spin down https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1073137

I can confirm the issue for Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-32-generic x86_64), jbd is hitting the disk every 4-5 sec on this server.

Same here with ubuntu 12.10

any update for this bug? I can not work on my desktop right now.

Update is that its has nothing to do with jbd2. In my case its chrome, jdb2 is only writing stuff to disk if a app is telling it to do so. Check iotop witch app triggers jdb2 and file a bug report for that app. Pretty sure you are using chrome.

Ubuntu 12.04.1

Same annoying problem here. JBD2 is causing EXTREMELY high IO everytime. Next iotop sample belongs to a large file writing through NFS:

$ sudo iotop -oq

Total DISK READ: 0.00 B/s | Total DISK WRITE: 1784.50 K/s
  239 be/3 root 0.00 B/s 0.00 B/s 0.00 % 99.65 % [jbd2/sdb1-8]
 1224 be/4 root 0.00 B/s 116.89 K/s 0.00 % 1.13 % [nfsd]
 1220 be/4 root 0.00 B/s 163.64 K/s 0.00 % 0.37 % [nfsd]
 1226 be/4 root 0.00 B/s 187.02 K/s 0.00 % 0.24 % [nfsd]
 1223 be/4 root 0.00 B/s 109.10 K/s 0.00 % 0.24 % [nfsd]
 1225 be/4 root 0.00 B/s 175.33 K/s 0.00 % 0.21 % [nfsd]
 1222 be/4 root 0.00 B/s 187.02 K/s 0.00 % 0.15 % [nfsd]
 1219 be/4 root 0.00 B/s 175.33 K/s 0.00 % 0.13 % [nfsd]
 1221 be/4 root 0.00 B/s 124.68 K/s 0.00 % 0.13 % [nfsd]

The file copy started OK (80 MB/s) and, after 1 or 2 minutes, speed dropped to barely 1 MB/s. As you can see, there are no other processes doing IO at this time. This behaviour appears randomly and VERY often, not necessarily when doing net IO, so my system becomes unresponsive again and again. Other OSes behave perfectly in this machine, so it's not a hardware issue.

Linux i7 3.8.0-0-generic #3-Ubuntu SMP Fri Jan 11 17:24:16 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
sudo iotop -oq

  327 be/3 root 0.00 B/s 23.70 K/s 0.00 % 2.66 % [jbd2/sdb1-8]
 1677 be/4 gert 0.00 B/s 27.65 K/s 0.00 % 0.03 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 39.50 K/s
  327 be/3 root 0.00 B/s 7.90 K/s 0.00 % 1.61 % [jbd2/sdb1-8]
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 221.21 K/s
  327 be/3 root 0.00 B/s 11.85 K/s 0.00 % 2.76 % [jbd2/sdb1-8]
 1678 be/4 gert 0.00 B/s 189.61 K/s 0.00 % 0.31 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 78.96 K/s
  327 be/3 root 0.00 B/s 7.90 K/s 0.00 % 2.20 % [jbd2/sdb1-8]
 1677 be/4 gert 0.00 B/s 27.64 K/s 0.00 % 0.04 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 39.50 K/s
  327 be/3 root 0.00 B/s 0.00 B/s 0.00 % 1.72 % [jbd2/sdb1-8]
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 201.42 K/s
  327 be/3 root 0.00 B/s 31.60 K/s 0.00 % 6.70 % [jbd2/sdb1-8]
 1631 be/4 gert 0.00 B/s 106.63 K/s 0.00 % 0.25 % chrome
 1666 be/4 gert 0.00 B/s 3.95 K/s 0.00 % 0.01 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 43.45 K/s
 1669 be/4 gert 0.00 B/s 15.80 K/s 0.00 % 0.00 % chrome
 1666 be/4 gert 0.00 B/s 3.95 K/s 0.00 % 0.00 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
 1669 be/4 gert 0.00 B/s 31.58 K/s 0.00 % 0.00 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 35.53 K/s
  327 be/3 root 0.00 B/s 7.90 K/s 0.00 % 1.76 % [jbd2/sdb1-8]
 1678 be/4 gert 0.00 B/s 15.79 K/s 0.00 % 0.09 % chrome
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 67.14 K/s
  327 be/3 root 0.00 B/s 3.95 K/s 0.00 % 2.21 % [jbd2/sdb1-8]
 1678 be/4 ge...

chrome closed
sudo iotop -oq

Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s

After getting really upset because of this issue (see comment #88), I decided to fully erase my HD and reinstall Ubuntu 12.04.1 again. Then I installed all applications I've been using before, and this problem fully disappeared. No idea of what was causing it, really. It remembers me those times when I was using Windows...

Seems like this bug causes corrupt file systems too:

Both used ext4 partitions show errors everytime after booting and running the affected OS. Errors include wrong counts of free blocks, zero dtime and orphaned inodes. The hardware is fine (according to smartctl) and errors don't occour after using the partitions via live disks (without the rampaging jdb2 process).
The installed OS is linux mint 13 (Linux version 3.2.0-26-generic (buildd@batsu) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012).

Just dist-upgraded from 12.04 to 12.10 and I have started noticing it here too. Not only the 'chkhkhk' every 10 seconds, verified by iotop, but every now and then there is a high-pitched very soft whine as though it is spinning... i can stop this simply by running 'find /' and hitting ctrl-c. I have tried kernel 3.2 and 3.5, same result.

I shut down firefox - still happens. Used elinks for a while. Still happens.

The noise is unbearable. I am going to have to switch to a different distro or something.

Had the same problem on lenovo x220 laptop under ubuntu 12.10 3.5.26
Fiddling with hdparm/apm had no effect.
Problem vanished after fsck'ing my ext4 partitions (in my case, using recovery mode menu option).

when I download a xml on firefox,it's about 1MB size,but firefox will be gray window,and system becomeslow down ,I type 'sudo iotop' on the terminal , jbd2/sdb3-8 is 98%io,jbd2 writing the disk all time,my disk is alway full work.my system is ubuntu 12.04 lts,Linux IT-Department 3.2.0-38-generic #61-Ubuntu SMP Tue Feb 19 12:18:21 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Notebook Lenovo G770

wad@wad-G770:~/$ cat /etc/*rele*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"
VERSION="13.04, Raring Ringtail"

wad@wad-G770:~/$ uname -a
Linux wad-G770 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

wad@wad-G770:~/$ sudo iotop -o -d 10
Total DISK READ: 125.85 K/s | Total DISK WRITE: 303.86 K/s
  TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
  282 be/3 root 0.00 B/s 12.74 K/s 0.00 % 84.76 % [jbd2/sda5-8]
 9228 be/4 wad 118.28 K/s 407.81 B/s 0.00 % 9.52 % geany
 9071 be/4 wad 0.00 B/s 93.59 K/s 0.00 % 0.46 % thunderbird
 9109 be/4 wad 407.81 B/s 6.37 K/s 0.00 % 0.15 % thunderbird
 9095 be/4 wad 0.00 B/s 121.47 K/s 0.00 % 0.00 % thunderbird

jbd2/sda5-8 takes up to 100% IO operation

wad@wad-G770:~$ cat /etc/fstab

UUID=d154600d-a0ba-494a-a7f2-74773fbe748b / ext4 errors=remount-ro 0 1

Linux xxxxxx 3.2.0-48-generic #74-Ubuntu SMP Thu Jun 6 19:43:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
 Manufacturer: Supermicro
 Product Name: H8SGL
I have this bug too. WTF?

Total DISK READ: 0.00 B/s | Total DISK WRITE: 7.06 M/s
  TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
32079 be/3 root 0.00 B/s 33.17 K/s 0.00 % 99.99 % [jbd2/dm-3-8]
  292 be/4 root 0.00 B/s 0.00 B/s 0.00 % 98.38 % [md0_raid1]
  337 be/3 root 0.00 B/s 3.69 K/s 0.00 % 0.00 % [jbd2/dm-0-8]
19735 be/4 www-data 0.00 B/s 3.69 K/s 0.00 % 0.00 % apache2 -k start
    1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
    2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
    3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]

rCX, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

I'm having a similar issue in Zentyal, which runs on top of Ubuntu 12.04.

Details:
http://forum.zentyal.org/index.php/topic,17925.0.html

Lonnie Lee Best / Rafael Duarte Vencioneck, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

I just want to confirm comment #94 of Vladimir Kononov (voldemark). After fsck on my disk drives (/ and /home) on a quite long time running (+1year) desktop install of debian mint on an old laptop the issue of high harddisk load seems to be minimized and system runs much more smoothly now.

So, please do fsck on your disks and update whether or not it solves the issue.

Peter M. Clausen, thank you for your comment. If you have a bug in Ubuntu (not mint, mint debian, etc.), please feel free to file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

I also can confirm that after tearing out my hair fsck the disk fixes the problem. A longer write up is here: http://www.advogato.org/person/berend/diary/397.html

Update: I was wrong. Thought I fixed it, but didn't. Moved to Ubuntu 13.10, which solved the problem. So I'm guessing it's a kernel bug.

Wrong again, got exactly the bad behaviour on Ubuntu 13.10. It's perhaps not related to the issue that started this thread, but since I posted here I thought I might as well inform anyone visiting this that my solution didn't work.

My current thinking is that if you have an NFS4 server with clients attached, and you reboot the server without detaching the clients, you get the bad behaviour. If you umount the clients first, then reboot the server, then mount the clients, the problem doesn't occur.

berend, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

This bug also conserns Lenovo B575e models.

Odd kworker and ext4lazyinit activity which results in constant hdd-activity light blinking. Interesting that this did'n _not_ affect ie. Ubuntu 14.04. Tested within about two hour timeframe.

Xubuntu 14.04
3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

:~$ sudo iotop -obtqqq

14:59:38 2451 idle man 0.00 B/s 1050.18 K/s 0.00 % 4.30 % mandb --quiet
14:59:39 143 be/3 root 0.00 B/s 90.60 K/s 0.00 % 71.89 % [jbd2/sda5-8]
14:59:39 2451 idle man 328.41 K/s 0.00 B/s 0.00 % 16.43 % mandb --quiet
14:59:39 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.33 % [kworker/u8:3]
14:59:40 143 be/3 root 0.00 B/s 102.14 K/s 0.00 % 79.94 % [jbd2/sda5-8]
14:59:40 2451 idle man 272.38 K/s 177.80 K/s 0.00 % 6.25 % mandb --quiet
14:59:40 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 4.01 % [ext4lazyinit]
14:59:40 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.42 % [kworker/u8:3]
14:59:41 143 be/3 root 0.00 B/s 79.35 K/s 0.00 % 90.75 % [jbd2/sda5-8]
14:59:41 2451 idle man 317.41 K/s 196.49 K/s 0.00 % 0.91 % mandb --quiet
14:59:41 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.36 % [kworker/u8:3]
14:59:42 143 be/3 root 0.00 B/s 79.22 K/s 0.00 % 80.29 % [jbd2/sda5-8]
14:59:42 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.46 % [kworker/u8:3]
14:59:42 823 be/4 syslog 0.00 B/s 3.77 K/s 0.00 % 0.00 % rsyslogd [rs:main Q:Reg]
14:59:42 956 be/4 root 0.00 B/s 3.77 K/s 0.00 % 0.00 % anacron -s
14:59:43 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.02 % [ext4lazyinit]
14:59:43 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.36 % [kworker/u8:3]
14:59:44 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.56 % [kworker/u8:3]
14:59:46 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 2.83 % [ext4lazyinit]
14:59:46 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.67 % [kworker/u8:3]
14:59:47 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.63 % [kworker/u8:3]
14:59:48 143 be/3 root 0.00 B/s 72.00 K/s 0.00 % 3.78 % [jbd2/sda5-8]
14:59:48 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.40 % [kworker/u8:3]
14:59:49 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.70 % [kworker/u8:3]
14:59:49 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.00 % [ext4lazyinit]
14:59:50 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.34 % [kworker/u8:3]
14:59:51 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.78 % [kworker/u8:3]
14:59:51 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 1.71 % [ext4lazyinit]
14:59:52 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.32 % [kworker/u8:3]
14:59:53 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 3.85 % [kworker/u8:3]
14:59:54 143 be/3 root 0.00 B/s 0.00 B/s 0.00 % 4.55 % [jbd2/sda5-8]
14:59:54 393 be/4 root 0.00 B/s 0.00 B/s 0.00 % 1.97 % [ext4lazyinit]
14:59:54 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.33 % [kworker/u8:3]
14:59:55 129 be/4 root 0.00 B/s 0.00 B/s 0.00 % ...

This version is now outdated and no more supported

I have this bug on Ubuntu 16.04. I am using 4.6.2 kernel. 4.4.6 have this bug too. What else information do you need?

Forgot to mention that the trouble starts with start of kernel, right after boot. And it affect not only Ubuntu. This bug was once fixed in 2.6 kernels and it worked up to 2.6.39.3, but then was a regression. Here's old patch, maybe it will be helpful:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e44718318004a5618d1dfe2d080e2862532d8e5f

Thinked some more. Journalling is just redirect of other apps, right? So I tried to disable journalling at all. And what do you think? Suddenly, another app was taking all I/O. It's "python onedrive-d start", glitchy sync app that I have been installed recently. Now my plot is:
1. Configure onedrive-d so it be not so intensive;
2. Re-enable journalling.
Solution is found, no glitchy commits is needed.

This bug is still NOT FIXED.
(Maybe once it was fixed, but now it is there again, so this is not related to old kernels, newer kernels suffer from this again. I think this thread must not be "invalid".)

I'm using Ubuntu MATE 17.04 64-bit,the kernel is 4.10.0-38-generic.
My system suffers from extreme disk usage by jbd2, so much that the constant "scratching" from the HDD is slowly drives me insane.

This bug maybe fixed, but it is already happening in various Linux distros, not just Ubuntu.
This bug drastically lowers the computer's performance and it's negatively affect the lifespan of HDDs, because of the extreme usage.
The noise from the HDD annoys the user and therefore can negatively affect the performance of their work, so this is a very important bug that must be fixed, once and for all. Fix it, And leave that part of the code alone. Forever.

Rencer, if you are having an issue in Ubuntu, the fastest way to getting it addressed is file a new report with Ubuntu by using the default repository kernel (not mainline/upstream/3rd party) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

I have a similar problem on a 4.15.0-20-generic kernel.
Is there a new bug for this since this one has been marked invalid?