summaryrefslogtreecommitdiff
path: root/fs/btrfs/compression.c
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2022-02-18 10:03:23 -0500
committerDavid Sterba <dsterba@suse.com>2022-03-14 13:13:51 +0100
commit1784b7d502a94b561eae58249adde5f72c26eb3c (patch)
treed9883e341cf061dbaad174891b50fcccb31b3cbf /fs/btrfs/compression.c
parent03ddb19d2ea745228879b9334f3b550c88acb10a (diff)
downloadlwn-1784b7d502a94b561eae58249adde5f72c26eb3c.tar.gz
lwn-1784b7d502a94b561eae58249adde5f72c26eb3c.zip
btrfs: handle csum lookup errors properly on reads
Currently any error we get while trying to lookup csums during reads shows up as a missing csum, and then on the read completion side we print an error saying there was a csum mismatch and we increase the device corruption count. However we could have gotten an EIO from the lookup. We could also be inside of a memory constrained container and gotten a ENOMEM while trying to do the read. In either case we don't want to make this look like a file system corruption problem, we want to make it look like the actual error it is. Capture any negative value, convert it to the appropriate blk_status_t, free the csum array if we have one and bail. Note: a possible improvement would be to make the relocation code look up the owning inode and see if it's marked as NODATASUM and set EXTENT_NODATASUM there, that way if there's corruption and there isn't a checksum when we want it we can fail here rather than later. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/compression.c')
0 files changed, 0 insertions, 0 deletions