aboutsummaryrefslogtreecommitdiffstats
path: root/fs/xfs
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2016-01-07 19:28:49 -0500
committerDave Chinner <david@fromorbit.com>2016-01-07 19:28:49 -0500
commite35438196c6a1d8b206471d51e80c380e80e047b (patch)
tree1081125d1c6e16dc251c1502b4e9bca9f65c5d43 /fs/xfs
parent121e213eabad66c0453904d76e3eda193958acbd (diff)
xfs: bmapbt checking on debug kernels too expensive
For large sparse or fragmented files, checking every single entry in the bmapbt on every operation is prohibitively expensive. Especially as such checks rarely discover problems during normal operations on high extent coutn files. Our regression tests don't tend to exercise files with hundreds of thousands to millions of extents, so mostly this isn't noticed. However, trying to run things like xfs_mdrestore of large filesystem dumps on a debug kernel quickly becomes impossible as the CPU is completely burnt up repeatedly walking the sparse file bmapbt that is generated for every allocation that is made. Hence, if the file has more than 10,000 extents, just don't bother with walking the tree to check it exhaustively. The btree code has checks that ensure that the newly inserted/removed/modified record is correctly ordered, so the entrie tree walk in thses cases has limited additional value. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'fs/xfs')
-rw-r--r--fs/xfs/libxfs/xfs_bmap.c10
1 files changed, 8 insertions, 2 deletions
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 73884953b21c..bc7e7d5b8c97 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -325,9 +325,11 @@ xfs_check_block(
325 325
326/* 326/*
327 * Check that the extents for the inode ip are in the right order in all 327 * Check that the extents for the inode ip are in the right order in all
328 * btree leaves. 328 * btree leaves. THis becomes prohibitively expensive for large extent count
329 * files, so don't bother with inodes that have more than 10,000 extents in
330 * them. The btree record ordering checks will still be done, so for such large
331 * bmapbt constructs that is going to catch most corruptions.
329 */ 332 */
330
331STATIC void 333STATIC void
332xfs_bmap_check_leaf_extents( 334xfs_bmap_check_leaf_extents(
333 xfs_btree_cur_t *cur, /* btree cursor or null */ 335 xfs_btree_cur_t *cur, /* btree cursor or null */
@@ -352,6 +354,10 @@ xfs_bmap_check_leaf_extents(
352 return; 354 return;
353 } 355 }
354 356
357 /* skip large extent count inodes */
358 if (ip->i_d.di_nextents > 10000)
359 return;
360
355 bno = NULLFSBLOCK; 361 bno = NULLFSBLOCK;
356 mp = ip->i_mount; 362 mp = ip->i_mount;
357 ifp = XFS_IFORK_PTR(ip, whichfork); 363 ifp = XFS_IFORK_PTR(ip, whichfork);