Your getting that issue because a transaction(write or delete) is stuck in the journal log and the disk doesnt match it.
How it works:
So when data is written 1st its written to journal then to disk (or at same time, but journal just saves metadata about the upcoming write - not sure... need more research on that part)...
Anyhow if you turn off the system in the middle of this write/delete or do something that hickups the system (dismount the USB that holds your btrfs mount point), then when it returns that mount will not work it will fail (dmesg and btrfsck will show you the errors in more detail)...
Looking at dmesg you will see those same transid messages.
You will see something like this:
parent transid verify failed on 109973766144 wanted 1823 found 1821
It means that btrfs wanted transid 1823 (That was on the journal) but on the disk it saw 1821. So the disk was 2 transactions away from being in sync with journal. I personally would risk a brtfs-zero-log here just because its only 2 transactions. But to be 100% safe if this is your only data (by the way if you have critical data you should NEVER EVER have only 1 copy of it, always have a copy/backup in a safe other location - blaming the creators of btrfs wouldnt justify against the persons own lack of responsibility of not having a backup - btrfs is not backup solution, its a filesystem - nothing is a true backup solution besides having a copy of it else where - not even parity or mirrored drives, a true backup is sitting somewhere underground in the Alps while its active copy is in your office in Texas)
parent transid verify failed on 31302336512 wanted 62455 found 62456
Here the journal is wanting 62455 but the disk is one ahead at 62456, so in your case i would just clear the journal. Journal didnt update this time. Again I told you bout being safe thing, if its your only data and its mega critical (shame on you), and I would do the below operations first to be safe.
Running a btrfsck /dev/sda5 (which by the way just does a readonly check so its completely safe, its only btrfsck options that you have to worry about) will also show you those messages.
But beware if that data is critical, i would first do (As the other gents said)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
Then cp or rsync all of your files over to safe location, then when safe do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)
Then if the mounts failed do a btrfs restore (dump of the system, as I understand its a resumeable operation, however it keeps asking for Y or y every now and again so watch the output)
btrfs restore /dev/sda5 /USB
Then when safe (when btrfs restore is done) do the btrfs-zero-log, if its a successful operation you just wasted alot of time backing up your system (but if its not successful, you just saved your arse)
You can run screen first
btrfs restore /dev/sda5 /USB
SCREEN SIDE NOTE
To detach (command will still run): CONTROL-a then type ":detach" without the quotes then press ENTER
Another way to detach: Then close out of putty or your terminal and it will detach (the command / restore will still run).
To check up on it, just screen back to it:
screen -x will attach to sessions, even if detached, and unlike -h says, it will attach even if its already attached as well)
If you have several screens, screen -x will tell you need to be more specific to attach to the session:
ls for list all sessions, easy to remember that.
to see the PID you can also do this:
ps aux | grep screen
Once you find out your PID, then run screen like this:
screen -x PID
That will attach to a specific session. You can have several sessions/puttys attached to the same screen (they will output the same text, you can type commands in one, and they will be mirrored on the other putty)