linux-ext4 - [Bug 42895] jbd2 makes all system unresponsive

lists.openwall.net		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]

Message-Id: <20120516202442.0132C11FCF8@bugzilla.kernel.org>
Date:	Wed, 16 May 2012 20:24:41 +0000 (UTC)
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 42895] jbd2 makes all system unresponsive

https://bugzilla.kernel.org/show_bug.cgi?id=42895

--- Comment #15 from Theodore Tso <tytso@....edu>  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
requirements.

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: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html