That should be OK. The caller will sit in that loop, sleeping in
congestion_wait(), polling the correct backing-dev occasionally and waiting
until the dirty limits subside to an acceptable limit, at which stage this:
if (nr_reclaimable +
global_page_state(NR_WRITEBACK)
<= dirty_thresh)
break;
will happen and we leave balance_dirty_pages().
That's all a bit crappy if the wrong races happen and some other task is
somehow exceeding the dirty limits each time this task polls them. Seems
unlikely that such a condition would persist forever.
So the question is, why do we have large amounts of dirty pages for one
disk which appear to be sitting there not getting written?
Do we know if there's any writeout at all happening when the system is in
this state?
I guess it's possible that the dirty inodes on the "other" disk got
themselves onto the wrong per-sb inode list, or are on the correct list,
but in the correct place. If so, these:
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-2.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-3.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-4.patch
writeback-fix-comment-use-helper-function.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-5.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-6.patch
writeback-fix-time-ordering-of-the-per-superblock-dirty-inode-lists-7.patch
writeback-fix-periodic-superblock-dirty-inode-flushing.patch
from 2.6.23-rc6-mm1 should help.
Did anyone try running /bin/sync when the system is in this state?
-
