Re: help request for an unmountable raid1 filesystem

[Glenn Trigg <ggtrigg@gmail.com>]

I wonder why this is not getting any replies?

On Sat, 23 Mar 2019 at 11:45, Glenn Trigg <ggtrigg@gmail.com> wrote:
>
> Hi,
>
> Since mailing this I have tried using the more recent utils - version
> btrfs-progs v4.20.2.
>
> I still have not had any success in getting the filesystem to a
> mountable state and I have now also tried recovering files with btrfs
> restore, also with no success. The restore output is:
>
> % ./btrfs restore -D /dev/sdc1 /data2/
> This is a dry-run, no files are going to be restored
> parent transid verify failed on 628168376320 wanted 37601 found 37712
> parent transid verify failed on 628168376320 wanted 37601 found 37712
> parent transid verify failed on 628168376320 wanted 37601 found 37712
> parent transid verify failed on 628168376320 wanted 37601 found 37712
> Ignoring transid failure
> ERROR: child eb corrupted: parent bytenr=628624064512 item=0 parent
> level=1 child level=1
> Error searching -5
>
> Is there something else I could do to recover either the filesystem or
> at least the files?
>
> Regards,
> Glenn
>
> On Sun, 10 Mar 2019 at 08:35, Glenn Trigg <ggtrigg@gmail.com> wrote:
> >
> > Hello,
> >
> > I had some random machine freezing events which I suspected was due to
> > issues with a raid1 filesystem and kernel module crashes. I attempted
> > to use the information available to get the filesystem into a good
> > state where "btrfs check" and "btrfs scrub" would not have any errors,
> > however I fear things have become worse.
> >
> > The current state of things is that the filesystem won't mount at all now.
> >
> > % mount -r /dev/sda1 /data
> > mount: /data: can't read superblock on /dev/sda1.
> >
> > and dmesg says:
> >
> > [15944.017629] BTRFS info (device sda1): disk space caching is enabled
> > [15944.017632] BTRFS info (device sda1): has skinny extents
> > [15944.024480] BTRFS info (device sda1): bdev /dev/sda1 errs: wr 0, rd
> > 0, flush 0, corrupt 1, gen 0
> > [15944.024487] BTRFS info (device sda1): bdev /dev/sdb1 errs: wr 0, rd
> > 0, flush 0, corrupt 4, gen 0
> > [15944.029292] BTRFS error (device sda1): parent transid verify failed
> > on 628168376320 wanted 37601 found 37700
> > [15944.029466] BTRFS error (device sda1): parent transid verify failed
> > on 628168376320 wanted 37601 found 37700
> >
> > Other system information is:
> > % uname -a
> > Linux izen 4.18.0-16-generic #17-Ubuntu SMP Fri Feb 8 00:06:57 UTC
> > 2019 x86_64 x86_64 x86_64 GNU/Linux
> >
> > % btrfs --version
> > btrfs-progs v4.16.1
> >
> > % btrfs fi show
> > Label: 'root'  uuid: 65fd7f11-4f60-435f-928b-6d15f12bc417
> > Total devices 1 FS bytes used 101.75GiB
> > devid    1 size 232.88GiB used 232.85GiB path /dev/nvme0n1p1
> >
> > Label: 'data'  uuid: d5e50511-3e31-4de6-ba37-c5841895be9f
> > Total devices 2 FS bytes used 830.44GiB
> > devid    1 size 1.82TiB used 669.03GiB path /dev/sda1
> > devid    2 size 1.82TiB used 817.06GiB path /dev/sdb1
> >
> > % btrfs check /dev/sda1
> > Checking filesystem on /dev/sda1
> > UUID: d5e50511-3e31-4de6-ba37-c5841895be9f
> > checking extents
> > parent transid verify failed on 628168343552 wanted 28163 found 37700
> > parent transid verify failed on 628168343552 wanted 28163 found 37700
> > parent transid verify failed on 628168343552 wanted 28163 found 37700
> > parent transid verify failed on 628168343552 wanted 28163 found 37700
> > Ignoring transid failure
> > bad block 628168343552
> > ERROR: errors found in extent allocation tree or chunk allocation
> > checking free space cache
> > cache and super generation don't match, space cache will be invalidated
> > checking fs roots
> > root 5 root dir 256 not found
> > ERROR: errors found in fs roots
> > found 528138240 bytes used, error(s) found
> > total csum bytes: 0
> > total tree bytes: 1785856
> > total fs tree bytes: 1064960
> > total extent tree bytes: 81920
> > btree space waste bytes: 606983
> > file data blocks allocated: 215220224
> >  referenced 215220224
> >
> > % btrfs rescue super-recover /dev/sda1
> > All supers are valid, no need to recover
> >
> > Where do I go from here?
> >
> > Regards,
> > Glenn