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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
