summaryrefslogtreecommitdiffstats
path: root/include/keys/asymmetric-subtype.h
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2014-05-07 08:05:52 +1000
committerDave Chinner <david@fromorbit.com>2014-05-07 08:05:52 +1000
commit8cfcc3e565bf15870efe801368a25ca98092e6e7 (patch)
tree87fd37e53b238733e3e214d35f799aabe7286127 /include/keys/asymmetric-subtype.h
parentac983517ec5941da0c58cacdbad10a231dc4e001 (diff)
xfs: fix directory readahead offset off-by-one
Directory readahead can throw loud scary but harmless warnings when multiblock directories are in use a specific pattern of discontiguous blocks are found in the directory. That is, if a hole follows a discontiguous block, it will throw a warning like: XFS (dm-1): xfs_da_do_buf: bno 637 dir: inode 34363923462 XFS (dm-1): [00] br_startoff 637 br_startblock 1917954575 br_blockcount 1 br_state 0 XFS (dm-1): [01] br_startoff 638 br_startblock -2 br_blockcount 1 br_state 0 And dump a stack trace. This is because the readahead offset increment loop does a double increment of the block index - it does an increment for the loop iteration as well as increase the loop counter by the number of blocks in the extent. As a result, the readahead offset does not get incremented correctly for discontiguous blocks and hence can ask for readahead of a directory block from an offset part way through a directory block. If that directory block is followed by a hole, it will trigger a mapping warning like the above. The bad readahead will be ignored, though, because the main directory block read loop uses the correct mapping offsets rather than the readahead offset and so will ignore the bad readahead altogether. Fix the warning by ensuring that the readahead offset is correctly incremented. Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Dave Chinner <david@fromorbit.com>
Diffstat (limited to 'include/keys/asymmetric-subtype.h')
0 files changed, 0 insertions, 0 deletions