FYI: According to ddrescue, there were read errors in +45% of the partition. There were no chances to save anything from the disk.
2018-08-01 15:07 GMT+03:00 Cerem Cem ASLAN <cerem...@ceremcem.net>: > 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 >> > >
