projects / thirdparty / kernel / stable-queue.git / blame
| Commit | Line | Data |
|---|---|---|
| cc67517a GKH |
1 | From david@fromorbit.com Fri Apr 2 11:09:55 2010 |
| 2 | From: Dave Chinner <david@fromorbit.com> | |
| 3 | Date: Fri, 12 Mar 2010 09:42:10 +1100 | |
| 4 | Subject: xfs: reclaim all inodes by background tree walks | |
| 5 | To: stable@kernel.org | |
| 6 | Cc: xfs@oss.sgi.com | |
| 7 | Message-ID: <1268347337-7160-13-git-send-email-david@fromorbit.com> | |
| 8 | ||
| 9 | From: Dave Chinner <david@fromorbit.com> | |
| 10 | ||
| 11 | commit 57817c68229984818fea9e614d6f95249c3fb098 upstream | |
| 12 | ||
| 13 | We cannot do direct inode reclaim without taking the flush lock to | |
| 14 | ensure that we do not reclaim an inode under IO. We check the inode | |
| 15 | is clean before doing direct reclaim, but this is not good enough | |
| 16 | because the inode flush code marks the inode clean once it has | |
| 17 | copied the in-core dirty state to the backing buffer. | |
| 18 | ||
| 19 | It is the flush lock that determines whether the inode is still | |
| 20 | under IO, even though it is marked clean, and the inode is still | |
| 21 | required at IO completion so we can't reclaim it even though it is | |
| 22 | clean in core. Hence the requirement that we need to take the flush | |
| 23 | lock even on clean inodes because this guarantees that the inode | |
| 24 | writeback IO has completed and it is safe to reclaim the inode. | |
| 25 | ||
| 26 | With delayed write inode flushing, we could end up waiting a long | |
| 27 | time on the flush lock even for a clean inode. The background | |
| 28 | reclaim already handles this efficiently, so avoid all the problems | |
| 29 | by killing the direct reclaim path altogether. | |
| 30 | ||
| 31 | Signed-off-by: Dave Chinner <david@fromorbit.com> | |
| 32 | Reviewed-by: Christoph Hellwig <hch@lst.de> | |
| 33 | Signed-off-by: Alex Elder <aelder@sgi.com> | |
| 34 | Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> | |
| 35 | ||
| 36 | --- | |
| 37 | fs/xfs/linux-2.6/xfs_super.c | 14 ++++++-------- | |
| 38 | 1 file changed, 6 insertions(+), 8 deletions(-) | |
| 39 | ||
| 40 | --- a/fs/xfs/linux-2.6/xfs_super.c | |
| 41 | +++ b/fs/xfs/linux-2.6/xfs_super.c | |
| 42 | @@ -953,16 +953,14 @@ xfs_fs_destroy_inode( | |
| 43 | ASSERT_ALWAYS(!xfs_iflags_test(ip, XFS_IRECLAIM)); | |
| 44 | ||
| 45 | /* | |
| 46 | - * If we have nothing to flush with this inode then complete the | |
| 47 | - * teardown now, otherwise delay the flush operation. | |
| 48 | + * We always use background reclaim here because even if the | |
| 49 | + * inode is clean, it still may be under IO and hence we have | |
| 50 | + * to take the flush lock. The background reclaim path handles | |
| 51 | + * this more efficiently than we can here, so simply let background | |
| 52 | + * reclaim tear down all inodes. | |
| 53 | */ | |
| 54 | - if (!xfs_inode_clean(ip)) { | |
| 55 | - xfs_inode_set_reclaim_tag(ip); | |
| 56 | - return; | |
| 57 | - } | |
| 58 | - | |
| 59 | out_reclaim: | |
| 60 | - xfs_ireclaim(ip); | |
| 61 | + xfs_inode_set_reclaim_tag(ip); | |
| 62 | } | |
| 63 | ||
| 64 | /* |