Yes, command output is as is, because I just copied and pasted into the mail. When I omit the `-t btrfs` part, result is the same. 

I'm now trying to rescue what I can, so getting a image dump with `ddrescue`. It's read about 25% without any errors but it will be expected to finish in 6 hours. Then I'll try btrfscue to see what happens. 

I know it's totally my fault because I must be ready for a total disk/pc/building burn out. Lessons learned. 

2018-08-01 8:32 GMT+03:00 Chris Murphy <lists@colorremedies.com>:
On Tue, Jul 31, 2018 at 12:03 PM, Cerem Cem ASLAN <ceremcem@ceremcem.net> wrote:

> 3. mount -t btrfs /dev/mapper/foo--vg-root /mnt/foo
> Gives the following error:
>
> mount: wrong fs type, bad option, bad superblock on ...
>
> 4. dmesg | tail
> Outputs the following:
>
>
> [17755.840916] sd 3:0:0:0: [sda] tag#0 FAILED Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> [17755.840919] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 07 c0 02 00 00
> 02 00
> [17755.840921] blk_update_request: I/O error, dev sda, sector 507906
> [17755.840941] EXT4-fs (dm-4): unable to read superblock


Are you sure this is the output for the command? Because you're
explicitly asking for type btrfs, which fails, and then the kernel
reports EXT4 superblock unreadable. What do you get if you omit -t
btrfs and just let it autodetect?

But yeah, this is an IO error from the device and there's nothing
Btrfs can do about that unless there is DUP or raid1+ metadata
available.

Is it possible this LV was accidentally reformatted ext4?


--
Chris Murphy