diff options
| author | Darrick J. Wong <darrick.wong@oracle.com> | 2017-06-16 11:00:12 -0700 |
|---|---|---|
| committer | Darrick J. Wong <darrick.wong@oracle.com> | 2017-06-20 10:45:21 -0700 |
| commit | d29cb3e45e923715f74d8a08d5c1ea996dce5a59 (patch) | |
| tree | 1d9224fcb46576b180f587609419b2ea53de1e76 /lib/rhashtable.c | |
| parent | ea7cdd7b7baffc40d1e60de7c93e5b1aabb3d081 (diff) | |
xfs: make _bmap_count_blocks consistent wrt delalloc extent behavior
There is an inconsistency in the way that _bmap_count_blocks deals with
delalloc reservations -- if the specified fork is in extents format,
*count is set to the total number of blocks referenced by the in-core
fork, including delalloc extents. However, if the fork is in btree
format, *count is set to the number of blocks referenced by the on-disk
fork, which does /not/ include delalloc extents.
For the lone existing caller of _bmap_count_blocks this hasn't been an
issue because the function is only used to count xattr fork blocks
(where there aren't any delalloc reservations). However, when scrub
comes along it will use this same function to check di_nblocks against
both on-disk extent maps, so we need this behavior to be consistent.
Therefore, fix _bmap_count_leaves not to include delalloc extents and
remove unnecessary parameters.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Diffstat (limited to 'lib/rhashtable.c')
0 files changed, 0 insertions, 0 deletions