]> www.infradead.org Git - users/jedix/linux-maple.git/commit
xfs: log all dirty inodes in xfs_fs_sync_fs
authorChristoph Hellwig <hch@infradead.org>
Wed, 4 Jan 2012 14:48:36 +0000 (09:48 -0500)
committerMaxim Uvarov <maxim.uvarov@oracle.com>
Tue, 10 Jan 2012 21:04:24 +0000 (13:04 -0800)
commitd736dd1c9e31dc94f24143b5c698d5b0347fa689
treef7397fe563a1e2d7ac3e32a05fb48d591b198e73
parent2273fbd3ac08dc372f02a23d3a75f9983630a5de
xfs: log all dirty inodes in xfs_fs_sync_fs

Commit be4f1ac828776bbc7868a68b465cd8eedb733cfd upstream.

Since Linux 2.6.36 the writeback code has introduces various measures for
live lock prevention during sync().  Unfortunately some of these are
actively harmful for the XFS model, where the inode gets marked dirty for
metadata from the data I/O handler.

The older_than_this checks that are now more strictly enforced since

    writeback: avoid livelocking WB_SYNC_ALL writeback

by only calling into __writeback_inodes_sb and thus only sampling the
current cut off time once.  But on a slow enough devices the previous
asynchronous sync pass might not have fully completed yet, and thus XFS
might mark metadata dirty only after that sampling of the cut off time for
the blocking pass already happened.  I have not myself reproduced this
myself on a real system, but by introducing artificial delay into the
XFS I/O completion workqueues it can be reproduced easily.

Fix this by iterating over all XFS inodes in ->sync_fs and log all that
are dirty.  This might log inode that only got redirtied after the
previous pass, but given how cheap delayed logging of inodes is it
isn't a major concern for performance.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/xfs/linux-2.6/xfs_sync.c
fs/xfs/linux-2.6/xfs_sync.h