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 <nbori...@suse.com>
Reviewed-by: Su Yue <suy.f...@cn.fujitsu.com>
> ---
> 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;
> }
>
pEpkey.asc
Description: application/pgp-keys
