>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
