So, no advice on how this could have happened? Ok, maybe it won't happen again... On Sun, Mar 3, 2013 at 5:44 PM, Alex Lyakas <alex.btrfs@xxxxxxxxxxxxxxxxx> wrote: > Hi Chris, > > On Sun, Mar 3, 2013 at 5:28 PM, Chris Mason <chris.mason@xxxxxxxxxxxx> wrote: >> On Sun, Mar 03, 2013 at 06:40:50AM -0700, Alex Lyakas wrote: >>> Greetings all, >>> I have an extent tree that looks like follows: >>> >>> item 22 key (27059916800 EXTENT_ITEM 16384) itemoff 2656 itemsize 24 >>> extent refs 1 gen 164 flags 1 >>> item 23 key (27059916800 EXTENT_ITEM 98304) itemoff 2603 itemsize 53 >>> extent refs 1 gen 165 flags 1 >>> extent data backref root 257 objectid 257 offset 17446191104 count 1 >>> item 24 key (27059916800 SHARED_DATA_REF 47169536) itemoff 2599 itemsize 4 >>> shared data backref count 1 >> >> Have you been experimenting on this FS with snapshot deletion patches? > > No, I haven't applied any patches on top of the commit I mentioned. (I > presume you mean David's patch for one-by-one deletion). Since > created, this FS has only seen straight IO with parallel snapshot > creation and deletion. However, the kernel was crashing pretty > frequently during this test, so I presume log replay was taking place. > > Any particular thing I can look for in the debug-tree output, except > searching for more double-allocations? > > Thanks, > Alex. > > >> >> -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
