[Bug 20902] High IO wait when writing to ext4

[bugzilla-daemon@bugzilla.kernel.org]

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





--- Comment #20 from Theodore Tso <tytso@mit.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.