Re: New file system with same issue (was: Again, no space left on device while rebalancing and recipe doesnt work)

[Henk Slager <eye1tm@gmail.com>]

>> BTW, I restored and mounted your 20160307-fanbtr-image:
>>
>> [266169.207952] BTRFS: device label fanbtr devid 1 transid 22215732 /dev/loop0
>> [266203.734804] BTRFS info (device loop0): disk space caching is enabled
>> [266203.734806] BTRFS: has skinny extents
>> [266204.022175] BTRFS: checking UUID tree
>> [266239.407249] attempt to access beyond end of device
>> [266239.407252] loop0: rw=1073, want=715202688, limit=705760000
>> [266239.407254] BTRFS error (device loop0): bdev /dev/loop0 errs: wr
>> 1, rd 0, flush 0, corrupt 0, gen 0
>> [266239.407272] attempt to access beyond end of device
>> .. and 16 more
>>
>> As a quick fix/workaround, I truncated the image to 1T
>
> The original fs was 417 GiB in size. What size does the image claim?

ls -alFh  of the restored image showed 337G I remember.
btrfs fi us showed also a number over 400G, I don't have the
files/loopdev anymore.
It could some side effect of btrfs-image, I only have used it for
multi-device, where dev id's are ignore, but total image size did not
lead to problems.

> [10/509]mh@fan:~$ sudo btrfs check /media/tempdisk/
> Superblock bytenr is larger than device size
> Couldn't open file system
> [11/509]mh@fan:~$
>
> Can this be fixed?

What I would do in order to fix it, is resize the fs to let's say
190GiB. That should write correct values to the superblocks I /hope/.
And then resize back to max.
Maybe btrfs check --repair can also fix it, but before doing --repair
or other actions, I would see what else besides btrfs could be wrong,
see also suggestion of Holger. --repair can repair certain things, but
also destroy the fs.