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 <li...@colorremedies.com>: > On Tue, Jul 31, 2018 at 12:03 PM, Cerem Cem ASLAN <cerem...@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 >
