Re: btrfs scrub crashes OS

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

On 2017年09月26日 17:26, Lukas Pirl wrote:
> Hi Qu,
> 
> On 09/26/2017 10:51 AM, Qu Wenruo wrote as excerpted:
>> This make things more weird.
>> Just in case, are you executing offline scrub by "btrfs scrub start
>> --offline <device>"
> 
> Yes. I even got some output (pretty sure the last lines are missing due
> to the crash):
> 
> WARNING: Offline scrub doesn't support extra options other than -r
> [I gave -d as well]
> Invalid mapping for 644337258496-644337332224, got
> 645348196352-646421938176
> Couldn't map the block 644337258496

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>

> ERROR: failed to read out data at bytenr 644337258496 mirror 1
> Invalid mapping for 653402148864-653402152960, got
> 653938130944-655011872768
> Couldn't map the block 653402148864
> ERROR: failed to read out data at bytenr 653402148864 mirror 1
> Invalid mapping for 717315420160-717315526656, got
> 718362640384-719436382208
> Couldn't map the block 717315420160
> ERROR: failed to read out data at bytenr 717315420160 mirror 1
> Invalid mapping for 875072008192-875072040960, got
> 875128946688-876202688512
> Couldn't map the block 875072008192
> ERROR: failed to read tree block 875072008192 mirror 1
> ERROR: extent 875072008192 len 32768 CORRUPTED: all mirror(s)
> corrupted, can't be recovered
> 
> Can I find out on which disk a mirror of a block is?

btrfs-map-logical can help you.
But I doubt if the offline scrub code, especially the new 
btrfs_map_block_v2() has hidden bug which caused the problem.

Withouth chunk tree dump, I am not which if it's a real bug or missing 
device.

Thanks,
Qu
> 
>> If so, I think there may be some problem outside the btrfs territory.
> 
> Of course, that is a possibility…
> 
>> Offline scrub has nothing to do with btrfs kernel module, it just reads
>> out on-disk data and verify checksum in *user* space.
>>
>> So if offline scrub can also screw up the system, it means there is
>> something wrong in the disk IO routine, not btrfs.
>>
>> And scrub can trigger it because normal btrfs IO won't try to read that
>> part/mirror.
> 
> …especially when considering this.
> 
>> What about trying to read all data out of your raw disk?
>> If offline crashes the system, reading the disk may crash it also.
>> Using dd to read each of your disk (with btrfs unmounted) may expose
>> which disk caused the problem.
> 
> That it is good idea! Will go ahead.
> 
> Thanks for your help so far.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>