On 06/05/2018 07:39 PM, Nikolay Borisov wrote:
> When btrfs check detects a freespace tree extent which ends beyond the
> blockgroup containing it a misleading error messages is printed. For
> example if we have the following extent in the freespace tree:
>
> item 5 key (30408704 FREE_SPACE_INFO 1073741824) itemoff 16259 itemsize 8
> free space info extent count 3 flags 0
> item 6 key (30425088 FREE_SPACE_EXTENT 49152) itemoff 16259 itemsize 0
> free space extent
> item 7 key (30507008 FREE_SPACE_EXTENT 65536) itemoff 16259 itemsize 0
> free space extent
> item 8 key (30654464 FREE_SPACE_EXTENT 14524648038063310901) itemoff 16259 itemsize 0
>
> Clearly the last extent is corrupted so we should print something
> along the lines of:
>
> free space extent ends at 14524648038063310901, beyond end of block group 30408704-1104150528
>
> Instead currently this is printed:
>
> free space extent ends at 30654464, beyond end of block group 30408704-1104150528
>
> So instead of printing the actual erroneous end, we print the beginning
> of the extent. Fix this by printing the actual corrupted end.
>
> Signed-off-by: Nikolay Borisov <nborisov@xxxxxxxx>
Reviewed-by: Su Yue <suy.fnst@xxxxxxxxxxxxxx>
> ---
> free-space-tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/free-space-tree.c b/free-space-tree.c
> index 69a4eca8a74f..747f8778e610 100644
> --- a/free-space-tree.c
> +++ b/free-space-tree.c
> @@ -276,7 +276,7 @@ static int load_free_space_extents(struct btrfs_fs_info *fs_info,
> if (key.objectid + key.offset > end) {
> fprintf(stderr,
> "free space extent ends at %llu, beyond end of block group %llu-%llu\n",
> - key.objectid, start, end);
> + key.objectid+key.offset, start, end);
> (*errors)++;
> break;
> }
>
Attachment:
pEpkey.asc
Description: application/pgp-keys
