writeback: don't delay inodes redirtied by a fast dirtier
commitb3af9468aebf5fcb573d0a116b31d2be1d43c0e9
authorWu Fengguang <fengguang.wu@intel.com>
Fri, 25 Sep 2009 04:04:10 +0000 (25 06:04 +0200)
committerJens Axboe <jens.axboe@oracle.com>
Fri, 25 Sep 2009 16:08:26 +0000 (25 18:08 +0200)
tree3af10b5fa82213345ea61d4ee23ba4a550a6077e
parent9ecc2738ac2371f88dff5d48914b4e35c45203cd
writeback: don't delay inodes redirtied by a fast dirtier

Debug traces show that in per-bdi writeback, the inode under writeback
almost always get redirtied by a busy dirtier.  We used to call
redirty_tail() in this case, which could delay inode for up to 30s.

This is unacceptable because it now happens so frequently for plain cp/dd,
that the accumulated delays could make writeback of big files very slow.

So let's distinguish between data redirty and metadata only redirty.
The first one is caused by a busy dirtier, while the latter one could
happen in XFS, NFS, etc. when they are doing delalloc or updating isize.

The inode being busy dirtied will now be requeued for next io, while
the inode being redirtied by fs will continue to be delayed to avoid
repeated IO.

CC: Jan Kara <jack@suse.cz>
CC: Theodore Ts'o <tytso@mit.edu>
CC: Dave Chinner <david@fromorbit.com>
CC: Chris Mason <chris.mason@oracle.com>
CC: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
fs/fs-writeback.c