That might be the case. Can't we recover anything with some data loss?

2018-08-01 2:04 GMT+03:00 Hans van Kranenburg <
hans.van.kranenburg@mendix.com>:

> Hi,
>
> On 07/31/2018 08:03 PM, Cerem Cem ASLAN wrote:
> > Hi,
> >
> > I'm having trouble with my server setup, which contains a BTRFS root
> > partition on top of LVM on top of LUKS partition.
> >
> > Yesterday server was shut down unexpectedly. I booted the system with a
> > pendrive which contains Debian 4.9.18 and tried to mount the BTRFS root
> > partition manually.
> >
> > 1. cryptsetup luksOpen /dev/sda5
> >
> > Seems to decrypt the partition (there are no errors)
> >
> > 2. /dev/mapper/foo--vg-root and /dev/mapper/foo--vg-swap_1 is created
> > automatically, so I suppose LVM works correctly.
> >
> > 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
> >     [18140.052300] sd 3:0:0:0: [sda] tag#0 FAILED Result:
> >     hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> >     [18140.052305] sd 3:0:0:0: [sda] tag#0 CDB: ATA command pass
> >     through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
> >     [18142.991851] sd 3:0:0:0: [sda] tag#0 FAILED Result:
> >     hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
> >     [18142.991856] sd 3:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 00 07 c0
> >     80 00 00 08 00
> >     [18142.991860] blk_update_request: I/O error, dev sda, sector 508032
> >     [18142.991869] Buffer I/O error on dev dm-4, logical block 16, async
> >     page read
>
> This points at hardware level failure, regardless if the disk would hold
> a btrfs or ext4 or whatever other kind of filesystem. The disk itself
> cannot read data back when we ask for it.
>
> > 4.
> >
> >     # btrfs restore -i -D /dev/mapper/foo--vg-root /dev/null
> >     No valid Btrfs found on /dev/mapper/foo--vg-root
> >     Could not open root, trying backup super
> >     No valid Btrfs found on /dev/mapper/foo--vg-root
> >     Could not open root, trying backup super
> >     No valid Btrfs found on /dev/mapper/foo--vg-root
> >     Could not open root, trying backup super
> >
> > We are pretty sure that no unexpected electric cuts has been happened.
> >
> > At this point I don't know what information I should supply.
> >
>
>
> --
> Hans van Kranenburg
>