linux-ext4 - [Bug 20902] High IO wait when writing to ext4

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: <201011251530.oAPFUkxi019525@demeter1.kernel.org>
Date:	Thu, 25 Nov 2010 15:30:46 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 20902] High IO wait when writing to ext4

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





--- Comment #20 from Theodore Tso <tytso@....edu>  2010-11-25 15:30:45 ---
Curtw's patch (at commit id: 8a57d9d61) also fixes the problem in the steady
state, once all of the block bitmap's statistics are loaded into memory.   So
one thing we could do is to simply force the block bitmap scan at mount time. 
It doesn't so much solve the problem as it moves it to a time when it might be
less objectionable.  For 8TB file systems if it really does take 10 minutes
then we would have to mitigate this by (a) having mke2fs use a larger flex_bg
size automatically, and/or (b) loading up the block bitmap statistics in
parallel (which will help on RAID systems, but not when we have 8TB on a single
spindle; given that 3 and 4 TB disks are within the horizon in the next couple
of years, 8TB/spindle aren't that far out of reach).

Storing the largest contiguous free extent in a block group in the block group
might be another way of solving this problem.  The reason why I don't like this
approach, though, is that it forces the implementation details of the buddy
bitmap implementation into the file system format.  It's possible that we might
have N blocks free, where N might be say (for the sake of argument) 256 blocks.
 But if those N blocks aren't aligned on a buddy bitmap allocation boundary,
mballoc won't find that free extent.  It might see it as a free regions that
are 31 blocks, 32 blocks, 128 blocks, 64 blocks, and 1 block free.

-- 
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