Re: [PATCH 1/8] btrfs: make search_csum_tree return 0 if we get -EFBIG

[Boris Burkov <boris@bur.io>]

On Thu, Feb 10, 2022 at 05:44:19PM -0500, Josef Bacik wrote:
> We can either fail to find a csum entry at all and return -ENOENT, or we
> can find a range that is close, but return -EFBIG.  In essence these
> both mean the same thing when we are doing a lookup for a csum in an
> existing range, we didn't find a csum.  We want to treat both of these
> errors the same way, complain loudly that there wasn't a csum.  This
> currently happens anyway because we do
> 
> 	count = search_csum_tree();
> 	if (count <= 0) {
> 		// reloc and error handling
> 	}
> 
> however it forces us to incorrectly treat EIO or ENOMEM errors as on
> disk corruption.  Fix this by returning 0 if we get either -ENOENT or
> -EFBIG from btrfs_lookup_csum() so we can do proper error handling.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Boris Burkov <boris@bur.io>
> ---
>  fs/btrfs/file-item.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
> index 9a3de652ada8..efb24cc0b083 100644
> --- a/fs/btrfs/file-item.c
> +++ b/fs/btrfs/file-item.c
> @@ -305,7 +305,7 @@ static int search_csum_tree(struct btrfs_fs_info *fs_info,
>  	read_extent_buffer(path->nodes[0], dst, (unsigned long)item,
>  			ret * csum_size);
>  out:
> -	if (ret == -ENOENT)
> +	if (ret == -ENOENT || ret == -EFBIG)
>  		ret = 0;
>  	return ret;
>  }
> -- 
> 2.26.3
>