summaryrefslogtreecommitdiff
path: root/sound
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2010-08-24 11:42:41 +1000
committerGreg Kroah-Hartman <gregkh@suse.de>2010-09-20 13:36:06 -0700
commitefa1f7cba7a728169b7c797dc66cab2a9d8526de (patch)
tree1c26b2416a565cd9ab3bf461043a10884a9143bd /sound
parentcf4f5ceca8d72ee794410cb26dc4b64b11d4965f (diff)
downloadlwn-efa1f7cba7a728169b7c797dc66cab2a9d8526de.tar.gz
lwn-efa1f7cba7a728169b7c797dc66cab2a9d8526de.zip
xfs: ensure we mark all inodes in a freed cluster XFS_ISTALE
commit 5b3eed756cd37255cad1181bd86bfd0977e97953 upstream. Under heavy load parallel metadata loads (e.g. dbench), we can fail to mark all the inodes in a cluster being freed as XFS_ISTALE as we skip inodes we cannot get the XFS_ILOCK_EXCL or the flush lock on. When this happens and the inode cluster buffer has already been marked stale and freed, inode reclaim can try to write the inode out as it is dirty and not marked stale. This can result in writing th metadata to an freed extent, or in the case it has already been overwritten trigger a magic number check failure and return an EUCLEAN error such as: Filesystem "ram0": inode 0x442ba1 background reclaim flush failed with 117 Fix this by ensuring that we hoover up all in memory inodes in the cluster and mark them XFS_ISTALE when freeing the cluster. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions