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
>