last 3 weeks since the upgrade to 10a do i have to create at least 3 new images a week cause the current ones always get corrupted

 

this is what i see in the syslog

 

Nov 28 14:08:33 R2D2 kernel: parent transid verify failed on 1048788992 wanted 11774 found 11167 (Minor Issues)
Nov 28 14:08:33 R2D2 kernel: parent transid verify failed on 1048788992 wanted 11774 found 11167 (Minor Issues)
Nov 28 14:08:33 R2D2 kernel: ------------[ cut here ]------------
Nov 28 14:08:33 R2D2 kernel: WARNING: CPU: 3 PID: 1677 at fs/btrfs/super.c:259 __btrfs_abort_transaction+0x4b/0xfb() (Minor Issues)
Nov 28 14:08:33 R2D2 kernel: BTRFS: Transaction aborted (error -5) (Errors)
Nov 28 14:08:33 R2D2 kernel: Modules linked in: veth xt_nat ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat iptable_filter ip_tables md_mod tun i2c_i801 pata_jmicron r8169 mii sata_sil24 ahci libahci asus_atk0110 [last unloaded: md_mod] (Drive related)
Nov 28 14:08:33 R2D2 kernel: CPU: 3 PID: 1677 Comm: btrfs-transacti Not tainted 3.16.3-unRAID #3 (Errors)
Nov 28 14:08:33 R2D2 kernel: Hardware name: System manufacturer System Product Name/P7P55D-E LX, BIOS 1701    09/27/2012
Nov 28 14:08:33 R2D2 kernel: 0000000000000000 ffff8800c65efc60 ffffffff815d9532 ffff8800c65efca8
Nov 28 14:08:33 R2D2 kernel: ffff8800c65efc98 ffffffff81040687 ffffffff81294a12 00000000fffffffb
Nov 28 14:08:33 R2D2 kernel: ffff8801cc92e800 ffff8801d16716e0 ffffffff8161f080 ffff8800c65efcf8
Nov 28 14:08:33 R2D2 kernel: Call Trace: (Errors)
Nov 28 14:08:33 R2D2 kernel: [<ffffffff815d9532>] dump_stack+0x45/0x56
Nov 28 14:08:33 R2D2 kernel: [<ffffffff81040687>] warn_slowpath_common+0x75/0x8e
Nov 28 14:08:33 R2D2 kernel: [<ffffffff81294a12>] ? __btrfs_abort_transaction+0x4b/0xfb
Nov 28 14:08:33 R2D2 kernel: [<ffffffff810406e7>] warn_slowpath_fmt+0x47/0x49
Nov 28 14:08:33 R2D2 kernel: [<ffffffff81294a12>] __btrfs_abort_transaction+0x4b/0xfb
Nov 28 14:08:33 R2D2 kernel: [<ffffffff812ad233>] btrfs_update_root+0x120/0x1f9
Nov 28 14:08:33 R2D2 kernel: [<ffffffff812b8320>] commit_fs_roots.isra.18+0x10f/0x142
Nov 28 14:08:33 R2D2 kernel: [<ffffffff812b8faf>] btrfs_commit_transaction+0x3ae/0x86c
Nov 28 14:08:33 R2D2 kernel: [<ffffffff812b54d4>] transaction_kthread+0xf7/0x1c8
Nov 28 14:08:33 R2D2 kernel: [<ffffffff812b53dd>] ? btrfs_cleanup_transaction+0x45b/0x45b
Nov 28 14:08:33 R2D2 kernel: [<ffffffff810588ba>] kthread+0xd6/0xde
Nov 28 14:08:33 R2D2 kernel: [<ffffffff810587e4>] ? kthread_create_on_node+0x168/0x168
Nov 28 14:08:33 R2D2 kernel: [<ffffffff815df3bc>] ret_from_fork+0x7c/0xb0
Nov 28 14:08:33 R2D2 kernel: [<ffffffff810587e4>] ? kthread_create_on_node+0x168/0x168
Nov 28 14:08:33 R2D2 kernel: ---[ end trace 55c16dbfabc95cc5 ]---
Nov 28 14:08:33 R2D2 kernel: BTRFS: error (device loop8) in btrfs_update_root:152: errno=-5 IO failure (Errors)
Nov 28 14:08:33 R2D2 kernel: BTRFS info (device loop8): forced readonly
Nov 28 14:08:33 R2D2 kernel: BTRFS warning (device loop8): Skipping commit of aborted transaction. (Minor Issues)
Nov 28 14:08:33 R2D2 kernel: BTRFS: error (device loop8) in cleanup_transaction:1571: errno=-5 IO failure (Errors)

 

Beta9 didn't have this problem where i was good for months with same loop8 image

 

so what screwed this up ?

 

 

I have seen this happen if the disk the image sits on fills up even briefly. Not the loop device the physical disk the image is on.

 

There is a ticket about it

We are still actively investigating this issue.  Simple short term workaround is to move the docker image file to a non cache device / non btrfs partition. 

Doesnt that open you up to an exponentiation increase in disk usage? Possibly not a problem for most but people should be forewarned

How so?  The loopback image is still btrfs. The underlying physical disk filesystem doesn't matter.