Hi @Bar1
Please have patience, this is a small project, and much of the support provided (this included) is community driven.
Ultimately, the issue you’re experiencing is that after (assumedly) a dirty reboot, the BTRFS transaction log (log of write operations including delete) does not match what is on the disk.
In some cases, this is fairly innocuous, (for example “wanted 533 found 532” would mean you were only one write operation off.
Unfortunately, yours are way off, with over 200 transactions not written to the disk.
I’m guessing you were in the middle of a large operation when the system restarted unexpectedly.
This is a particularly bad state for BTRFS to be in.
There are a few ways to address this.
The first, and easiest, but least recommended for your case would be to zero out the log and ignore any changes that weren’t written:
btrfs zero-log /dev/<btrfs-device>
Note that you need to replace with your BTRFS device, after identifying it.
Instead, I would suggest attempting to mount the partition in recovery mode, and copy the contents elsewhere.
To do this, again you’ll need to know your BTRFS device location.
At that point, you can hopefully mount it with:
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
Failing that:
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/<btrfs-device> /mnt2
If you have mounted successfully, copy or rsync the contents elsewhere, then try the zero-log command above.
If that fails, dump the filesystem as follows:
btrfs restore /dev/<btrfs-device> <mounted-location-larger-than-btrfs-fs>
Then zero the log.
Failing that, nuke it from orbit and consider this a lesson in backing up critical data, regardless of the filesystem in use. (I say this with gritted teeth, having >13Tb of data with no suitable place to backup to)