> Scott E. Blomquist writes: > > Hi All, > > > > Early this morning there was a power glitch that affected our > > system. > > > > The second enclosure went offline but the file system stayed up > > for a bit before rebooting and recovering the 2 missing arrays > > sdb1 and sdc1. > > > > When mounting we get.... > > > > Aug 12 14:52:43 localhost kernel: [ 8536.649270] BTRFS info > > (device sda1): has skinny extents Aug 12 14:54:52 localhost > > kernel: [ 8665.900321] BTRFS error (device sda1): parent transid > > verify failed on 177443463479296 wanted 2159304 found 2159295 Aug > > 12 14:54:52 localhost kernel: [ 8665.985512] BTRFS error (device > > sda1): parent transid verify failed on 177443463479296 wanted > > 2159304 found 2159295 Aug 12 14:54:52 localhost kernel: > > [ 8666.056845] BTRFS error (device sda1): failed to read block > > groups: -5 Aug 12 14:54:52 localhost kernel: [ 8666.254178] BTRFS > > error (device sda1): open_ctree failed > > > > We are here... > > > > # uname -a > > Linux localhost 4.17.14-custom #1 SMP Sun Aug 12 11:54:00 EDT > > 2018 x86_64 x86_64 x86_64 GNU/Linux > > > > # btrfs --version > > btrfs-progs v4.17.1 > > > > # btrfs filesystem show > > Label: none uuid: 8337c837-58cb-430a-a929-7f6d2f50bdbb > > Total devices 3 FS bytes used 75.05TiB > > devid 1 size 47.30TiB used 42.07TiB path /dev/sda1 > > devid 2 size 21.83TiB used 16.61TiB path /dev/sdb1 > > devid 3 size 21.83TiB used 16.61TiB path /dev/sdc1 > > > > Thanks for any help. > > > > sb. Scott Blomquist > Hi All, > > Is there any more info needed here? > > I can restore from backup if needed but that will take a bit of time. > > Checking around it looks like I could try... > > btrfs-zero-log /dev/sda1 > > Or maybe .. > > btrfsck --repair /dev/sda1 > > I am just not sure here and would prefer to do the right thing. > > Any help would be much appreciated. > > Thanks, > > sb. Scott Blomquist > > I'm not a dev, just user. btrfs-zero-log is for very specific case[1], not for transid errors. Transid errors mean that some metadata writes are missing, if they prevent you from mounting filesystem it's pretty much fatal. If btrfs could recover metadata from good copy it'd have done that. "wanted 2159304 found 2159295" means that some metadata is stale by 9 commits. You could try to mount it with "ro,usebackuproot" mount options as readonly mount is less strict. If that works you can try "usebackuproot" without ro option. But 9 commits is probably too much and there isn't enough data to rollback so far. [1] https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log
