summaryrefslogtreecommitdiffstats
path: root/arch/x86
diff options
context:
space:
mode:
authorChristoph Hellwig <hch@infradead.org>2011-12-20 20:08:41 +0000
committerBen Myers <bpm@sgi.com>2011-12-23 16:41:47 -0600
commitbe4f1ac828776bbc7868a68b465cd8eedb733cfd (patch)
treee1200a933beeb93702ce0c571a4ca3304f3cab72 /arch/x86
parent0b8fd3033c308e4088760aa1d38ce77197b4e074 (diff)
downloadtalos-obmc-linux-be4f1ac828776bbc7868a68b465cd8eedb733cfd.tar.gz
talos-obmc-linux-be4f1ac828776bbc7868a68b465cd8eedb733cfd.zip
xfs: log all dirty inodes in xfs_fs_sync_fs
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>
Diffstat (limited to 'arch/x86')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud