Cache wont start ( Unmountable: No file system )

[eins]

Hi,

i noticed that one of my VMs had a filesystem error (filesystem in read only mode), so i tried restarting it. It did not come back up and started in an EFI shell, so i went into the VM config and wanted to remove some attached disks... well after saving the VM was gone from Unraid. I was also not able to re-create it, so i went into to console and noticed the whole cache filesystem was in read-only mode.

I completely restarted Unraid, and after i started the array i got the "Unmountable: No file system" error for my cache.

 

Diagnostics is attached

 

The two cache drives are

Samsung_SSD_850_PRO_512GB_S2BENWAJ803574W - 512 GB (sdg)

2CT500BX100SSD1_1452F000F1C4 - 500 GB (sdj)

 

 

EDIT:

 

I tried the part about unmountable btrfs filesystems from the FAQ

Quote

root@einsServ:~# mount -o usebackuproot,ro /dev/sdg1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.
root@einsServ:~# mount -o usebackuproot,ro /dev/sdj1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdj1, missing codepage or helper program, or other error.
root@einsServ:~# mount -o degraded,usebackuproot,ro /dev/sdg1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.
root@einsServ:~# mount -o degraded,usebackuproot,ro /dev/sdj1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdj1, missing codepage or helper program, or other error.
root@einsServ:~# mount -o ro,notreelog,nologreplay /dev/sdj1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdj1, missing codepage or helper program, or other error.
root@einsServ:~# mount -o ro,notreelog,nologreplay /dev/sdg1 /root/x
mount: /root/x: wrong fs type, bad option, bad superblock on /dev/sdg1, missing codepage or helper program, or other error.

 

btrfs restore seems to mostly work, but every file thats bigger than a few Megabytes seems to hang with an

"We seem to be looping a lot on /mnt/disk3/restore2/appdata/pihole/pihole/pihole-FTL.db, do you want to keep going on ? (y/N/a)" error...

 

einsserv-diagnostics-20210512-1653.zip

Edited May 12, 2021 by eins

[JorgeB]

Mount error suggests some writes were lost, see here for some recovery options, option #2 is the more likely to work with that error, if successful then reformat the pool.

[eins]

Thank you.

I just tried these, as written above, #1 didnt work at all, and #2 seems to "loop" on any file bigger than a few megabyte (like all the vm disk files...)

[JorgeB]

10 minutes ago, eins said:

seems to "loop"

That doesn't mean it won't work, let it run.

[eins]

I pressed "y" like 50 times and some files still seem to loop, so i went with "n"... after some research "a" seems to be the right answer to keep looping until the file is restored... looking into this and the (non existent) documentation on this topic makes me really loose trust in btrfs. Why is "a" even keep looping (figured it was "abort"), and why can't i pass this as an option when running restore, but have to do it for every single file?

Seems like there even is a open bug ticket about exactly this behavoir for over 1 year... what the hell btrfs?

[JorgeB]

1 minute ago, eins said:

Why is "a" even keep looping

a means always.

 

 

[JorgeB]

Also, and just FYI, those trans ID errors are usually caused by bad RAM or devices that don't respect write barriers or FUA, due to the very close transition ID difference I would suspect the latter.