BTRFS trouble - parent transid verify failed

Server: 2.1.19 on Ubuntu 16.04 (Kernel 4.8.0-46) guest on KVM raw image also on BTRFS (CoW disable for the disk)
Client: 2.1.15
This is not directly na urBackup problem (I think :wink: ).
But I think that a lot of you guys use BTRFS as backup storage location.

My disk with the backup storage location on it got the following error:
[ 192.930279] BTRFS error (device sdb): parent transid verify failed on 2261007073280 wanted 13181 found 13676
[ 192.930549] BTRFS error (device sdb): parent transid verify failed on 2261007073280 wanted 13181 found 13676
[ 192.930650] BTRFS warning (device sdb): Skipping commit of aborted transaction.
[ 192.930652] ------------[ cut here ]------------
[ 192.930709] WARNING: CPU: 0 PID: 1579 at /build/linux-hwe-f8QJ3c/linux-hwe-4.8.0/fs/btrfs/transaction.c:1854 cleanup_transaction+0x8e/0x2f0 [btrfs]
[ 192.930710] BTRFS: Transaction aborted (error -5)
[ 192.930711] Modules linked in: ppdev input_leds joydev serio_raw parport_pc parport ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear psmouse virtio_scsi ahci libahci virtio_net
[ 192.930737] CPU: 0 PID: 1579 Comm: btrfs Not tainted 4.8.0-46-generic #49~16.04.1-Ubuntu
[ 192.930738] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
[ 192.930740] 0000000000000286 0000000084d1f81f ffff917d4dec3ab0 ffffffffbc22e073
[ 192.930743] ffff917d4dec3b00 0000000000000000 ffff917d4dec3af0 ffffffffbbe8313b
[ 192.930745] 0000073ec058a6c6 ffff917d37250510 ffff917d7a16e000 ffff917d7c70d1e0
[ 192.930747] Call Trace:
[ 192.930753] [] dump_stack+0x63/0x90
[ 192.930756] [] __warn+0xcb/0xf0
[ 192.930758] [] warn_slowpath_fmt+0x5f/0x80
[ 192.930774] [] cleanup_transaction+0x8e/0x2f0 [btrfs]
[ 192.930776] [] ? wake_atomic_t_function+0x60/0x60
[ 192.930778] [] ? __wake_up+0x44/0x50
[ 192.930793] [] btrfs_commit_transaction+0x2e0/0xb00 [btrfs]
[ 192.930809] [] ? start_transaction+0x9e/0x4c0 [btrfs]
[ 192.930826] [] btrfs_mksubvol+0x57f/0x590 [btrfs]
[ 192.930828] [] ? wake_atomic_t_function+0x60/0x60
[ 192.930845] [] btrfs_ioctl_snap_create_transid+0x192/0x1a0 [btrfs]
[ 192.930862] [] btrfs_ioctl_snap_create_v2+0x125/0x170 [btrfs]
[ 192.930879] [] btrfs_ioctl+0x659/0x2010 [btrfs]
[ 192.930882] [] ? handle_mm_fault+0xdaa/0x1410
[ 192.930885] [] do_vfs_ioctl+0xa1/0x5f0
[ 192.930888] [] ? __do_page_fault+0x265/0x4e0
[ 192.930890] [] SyS_ioctl+0x79/0x90
[ 192.930893] [] entry_SYSCALL_64_fastpath+0x1e/0xa8
[ 192.930895] —[ end trace abf789c354e24c9a ]—
[ 192.930897] BTRFS: error (device sdb) in cleanup_transaction:1854: errno=-5 IO failure
[ 192.930985] BTRFS info (device sdb): forced readonly
[ 207.163991] BTRFS error (device sdb): parent transid verify failed on 2261033762816 wanted 13184 found 13680
[ 207.167882] BTRFS error (device sdb): parent transid verify failed on 2261033762816 wanted 13184 found 13680

I tried some of the proposed troubleshooting tips, but they didn’t help if not made it worse (not that I didn’t thought this possible :wink: ) I still have the problem, but other error messages.

My question to the community is what are your BTRFS troubleshooting tips for this and other BTRFS issues?

Thanks for your inputs.

Try irc, there s always a peoples in their channel

With this error (and you say you have others) it is unlikely that you can recover it to a read-write state again.

What you should look at is why this occured in the first place.

That is check

  • Drive barriers go through from guest to disk
  • Drive write-through, write-back is configured correctly
  • No firmware issues with disk
  • Use a more recent kernel, e.g. LTS 4.9.x

I’d also not use btrfs in the hypervisor but LVM (except if you want to have a lot of snapshots of your VMs). There could also be fsync, O_DIRECT issues in older btrfs versions which could explain the corruption in the host, but you didn’t say which kernel you use as hypervisor.