Thanks for all the help!
If I get a chance later today, I may try the patch set, but in
the interest of getting things back online quicker, I may just
have to recreate and restore the recovered data. The snapshots
are no great loss - they're just one level of daily backups.
On 2019/8/15 下午10:21, Tim Walberg wrote:
> 'dump-super -Ffa' from all three devices attached.
>
> 'btrfs restore' did appear to recover most of the main data, minus
> snapshots, which would have greatly increased the required time and
> capacity, since I was recovering to XFS.
That's why I reco
'dump-super -Ffa' from all three devices attached.
'btrfs restore' did appear to recover most of the main data, minus
snapshots, which would have greatly increased the required time and
capacity, since I was recovering to XFS.
'btrfs rescue chunk-recover' ran, but failed to fix anything.
'btrfs r
On 2019/8/15 下午9:52, Tim Walberg wrote:
> Had to wait for 'btrfs recover' to finish before I proceed farther.
>
> Kernel is 4.19.45, tools are 4.19.1
>
> File system is a 3-disk RAID10 with WD3003FZEX (WD Black 3TB)
>
> Output from attempting to mount:
>
> # mount -o ro,usebackuproot /dev/sdc
Also - here's 'btrfs inspect-internal dump-super /dev/sdc1':
superblock: bytenr=65536, device=/dev/sdc1
-
csum_type 0 (crc32c)
csum_size 4
csum 0x4331039b [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [
Had to wait for 'btrfs recover' to finish before I proceed farther.
Kernel is 4.19.45, tools are 4.19.1
File system is a 3-disk RAID10 with WD3003FZEX (WD Black 3TB)
Output from attempting to mount:
# mount -o ro,usebackuproot /dev/sdc1 /mnt
mount: wrong fs type, bad option, bad superblock on /
On 2019/8/15 上午2:32, Tim Walberg wrote:
> Most of the recommendations I've found online deal with when "wanted" is
> greater than "found", which, if I understand correctly means that one or
> more transactions were interrupted/lost before fully committed.
No matter what the case is, a proper tra
