lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 16 May 2012 20:24:41 +0000 (UTC)
Subject: [Bug 42895] jbd2 makes all system unresponsive

--- Comment #15 from Theodore Tso <>  2012-05-16 20:24:41 ---
Eugene, one thing which may not be obvious is that it's not the number of disk
blocks that are written; it's how often the disk drive seeks, and more
importantly, wakes up.  Once you wake up the hard drive, and the hard drive has
positioned the hard drive heads to the right place on disk, whether you write
8k or 32k or 128k doesn't make that much difference in terms of time and power

So for example, if gedit writes a single file, it might cause multiple jbd2
writes: for the block allocation bitmap, for the inode allocation bitmap, the
inode table, the block group summary block, and then the data block itself. 
But the jbd2 writes are contiguous, and happen all at once, during a journal
commit (which is caused either by an explicit fsync or by the 5 second commit
timer which starts a journal commit 5 seconds after metadata changes have been
applied to the file system).   So you might see "lots of jbd2 writes", but it's
misleading in terms of the power requirements or disk time fraction consumed by
the journalling.   Of course, if you don't care about consistency after a
crash, you can always disable journalling.  But then you might lose data files
after a system crash.

The bottom line is that if you want to keep the disk sleeping for longer, you
have to be absolutely firm about not having programs write to the file system. 
 For things like gedit, it's caused by user activity, and that's fine and good.
 But if NetworkManager is dirtying the disk every few seconds or minutes,
especially if it's something useless like some kind of timestamp file, it's a
bug that should be filed with extreme prejudice against NetworkManager, since
it's guaranteed to be constantly waking up the disk.

Configure bugmail:
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists