same EXTENT_ITEM appears twice in the extent tree

same EXTENT_ITEM appears twice in the extent tree

[Alex Lyakas]

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

As can be seen, same EXTENT_ITEM appears twice. This was undetected,
until __btrfs_free_extent was called, after cleaner deleted one of the
snapshots. Then it lead to assert:
		if (found_extent) {
			BUG_ON(is_data && refs_to_drop !=
			       extent_data_ref_count(root, path, iref));
			if (iref) {
				BUG_ON(path->slots[0] != extent_slot);
			} else {
				BUG_ON(path->slots[0] != extent_slot + 1);  /* CRASH */
				path->slots[0] = extent_slot;
				num_to_del = 2;
			}

As for the usage of this bad extent, there are multiple snapshots
sharing the 98304-length extent, but only one that uses the 16384
extent:
file tree key (257 ROOT_ITEM 0)
	item 19 key (257 EXTENT_DATA 17446191104) itemoff 2935 itemsize 53
		extent data disk byte 27059916800 nr 98304
		extent data offset 0 nr 98304 ram 98304
		extent compression 0
...
file tree key (350 ROOT_ITEM 164)
	item 21 key (257 EXTENT_DATA 17446191104) itemoff 2829 itemsize 53
		extent data disk byte 27059916800 nr 16384
		extent data offset 0 nr 16384 ram 16384
		extent compression 0

...
file tree key (352 ROOT_ITEM 167)
	item 19 key (257 EXTENT_DATA 17446191104) itemoff 2935 itemsize 53
		extent data disk byte 27059916800 nr 98304
		extent data offset 0 nr 98304 ram 98304
		extent compression 0

Kernel is "for-linus", top commit:

commit 1eafa6c73791e4f312324ddad9cbcaf6a1b6052b
Author: Miao Xie <miaox@cn.fujitsu.com>
Date:   Tue Jan 22 10:49:00 2013 +0000

    Btrfs: fix repeated delalloc work allocation

I believe I might have more extents like this, because btrfs-debug-tree warns:
warning, bad space info total_bytes 26851934208 used 26852773888
warning, bad space info total_bytes 27925676032 used 27926892544

Mount options: nodatasum,nodatacow,noatime,nospace_cache. Metadata
profile is DUP, data profile is single.

Can anybody advise on how this could have happened? I can provide the
whole debug-tree, btrfs-image or any additional info.

Thanks,
Alex.

Re: same EXTENT_ITEM appears twice in the extent tree

[Chris Mason]

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?

-chris

Re: same EXTENT_ITEM appears twice in the extent tree

[Alex Lyakas]

Hi Chris,

On Sun, Mar 3, 2013 at 5:28 PM, Chris Mason <chris.mason@fusionio.com> 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

Re: same EXTENT_ITEM appears twice in the extent tree

[Alex Lyakas]

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@zadarastorage.com> wrote:
> Hi Chris,
>
> On Sun, Mar 3, 2013 at 5:28 PM, Chris Mason <chris.mason@fusionio.com> 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