Hi Chris, Thanks for spending the time and energy to help me look into this.
btrfs restore isn't very happy either, so I guess I'll wait until btrfs-progs v5.0 comes out and see if that helps. btrfs restore says... % ./btrfs restore -v -D /dev/sda1 /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 and... % ./btrfs restore -l /dev/sda1 tree key (EXTENT_TREE ROOT_ITEM 0) 628168359936 level 1 tree key (DEV_TREE ROOT_ITEM 0) 628642152448 level 1 tree key (FS_TREE ROOT_ITEM 0) 628635549696 level 2 tree key (CSUM_TREE ROOT_ITEM 0) 628168343552 level 0 tree key (UUID_TREE ROOT_ITEM 0) 628810366976 level 0 tree key (DATA_RELOC_TREE ROOT_ITEM 0) 628168491008 level 0 Regards, Glenn On Tue, 2 Apr 2019 at 04:14, Chris Murphy <li...@colorremedies.com> wrote: > > On Sun, Mar 31, 2019 at 11:48 PM Glenn Trigg <ggtr...@gmail.com> wrote: > > > > Hi Chris, > > > > After booting the fedora usb stick (running rc2), I got the same results. > > > > On Mon, 1 Apr 2019 at 08:35, Chris Murphy <li...@colorremedies.com> wrote: > > > > > > On Sat, Mar 30, 2019 at 5:43 PM Glenn Trigg <ggtr...@gmail.com> wrote: > > ... > > > > > > I'm confused because "can't read superblock" isn't found in fs/btrfs. > > > I'm only finding it in fs/gfs2/ops_fstype.c > > > > > > From what you provided, /dev/sda1 definitely has a valid btrfs > > > superblock. I wonder if there's some other stale something or other on > > > this partition? > > > > > > What do you get for > > > > > > $ sudo blkid > > > > /dev/sda1: LABEL="data" UUID="d5e50511-3e31-4de6-ba37-c5841895be9f" > > UUID_SUB="a28b0f34-f14d-492b-995b-2dd8a78ec9bb" TYPE="btrfs" > > PARTUUID="efa240ec-01" > > /dev/sdc1: LABEL="data" UUID="d5e50511-3e31-4de6-ba37-c5841895be9f" > > UUID_SUB="d9c56d7a-21a1-4197-a701-5493392e1ae1" TYPE="btrfs" > > PARTUUID="1aae1443-c03e-4509-ad06-124a64c4df4f" > > > > > $ sudo wipefs -an /dev/sda1 /dev/sdc1 > > > > /dev/sda1: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 > > 52 66 53 5f 4d > > /dev/sdc1: 8 bytes were erased at offset 0x00010040 (btrfs): 5f 42 48 > > 52 66 53 5f 4d > > > > > $ sudo mount -v -o ro,nologreplay,usebackuproot > > > > mount: /data: can't read superblock on /dev/sda1. > > > > That is the sort of error I'd expect if the device were in fstab to be > mounted at /data. But you're running this mount command while booted > from the Fedora USB stick? I'm pretty lost at this point. > > Anyway, your best bet is to scrape with `btrfs restore` and then move > on, i.e. start over with a new file system. Right now I have no > confidence in the repair tools, but maybe a developer will come along > and offer some different advice on additional steps. For sure any of > the user space repair options are a last resort. There should be a > btrfs-progs 5.0 soon that is supposed to be safer, and might be worth > a shot. But I think it's a coin toss. > > > -- > Chris Murphy
