Re: btrfs scrub crashes OS

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2017年09月26日 19:50, Lukas Pirl wrote:
> On 09/26/2017 11:36 AM, Qu Wenruo wrote as excerpted:
>> This is strange, this means that we can't find a chunk map for a 72K
>> length data extent.
>>
>> Either the new mapper code has some bug, or it's a big problem.
>> But I think it's more possible for former case.
>>
>> Would you please try to dump the chunk tree (which should be quite
>> small) using the following command?
>>
>> $ btrfs inspect-internal dump-tree -t chunk <device>
> 
> Sure, happy to provide that:
>    https://static.lukas-pirl.de/dump-chunk-tree.txt
> (too large for Pastebin, file will probably go away in a couple of weeks).
> 

Found the needed info.

Your original data extent range is [644337258496, +72K].
Which is just in the range of the following 2 chunks:

---
	item 5 key (FIRST_CHUNK_TREE CHUNK_ITEM 643200712704) itemoff 15611 
itemsize 112
		length 1073741824 owner 2 stripe_len 65536 type DATA|RAID1
                 <snip>

	item 6 key (FIRST_CHUNK_TREE CHUNK_ITEM 645348196352) itemoff 15499 
itemsize 112
		length 1073741824 owner 2 stripe_len 65536 type DATA|RAID1
		io_align 65536 io_width 65536 sector_size 4096
                 <snip>
---
Those two chunks are covering the ranges of:
[643200712704, +1G)
[645348196352, +1G)

And no other chunk covers the hole between them.
But your original data extent range is in that hole.

So offline scrub output that error messages.
At least the chunk mapping code is correct.

Maybe something is wrong in the extent tree.
But anyway, it shouldn't cause too much trouble in offline scrub as you 
can see, it's a user space program and handles the problem quite well.
(Outputs error message and continue, without panic out)

So reading all your disk may still be needed to wipe out or confirm the 
possibility of the disk IO routine.

Thanks,
Qu

> Cheers,
> 
> Lukas
>