On 2020/5/22 下午5:40, Pierre Abbat wrote:
> On Thursday, May 21, 2020 9:32:54 PM EDT Qu Wenruo wrote:
>> Considering your btrfs check reports no serious problem, the hang looks
>> strange.
>>
>> The remaining possibility is the log tree.
>>
>> You could try to boot using any liveCD with new enough kernel, then
>> btrfs ins dump-super <device> | grep log_root
> 
> I can do that booted normally from the M.2. The output is
> log_root                862339072
> log_root_transid        0
> log_root_level          0
> 

So indeed log tree is involved.

>> If the result is not 0, then try btrfs rescue zero-log, then try mount
>> again.
> 
> You seem to be misunderstanding me. I'm not trying to fix the broken filesystem; 
> I already recovered the files to a new drive. I'm trying to give you enough 
> information to reproduce the hang in mount, so that you can fix the bug. If I 
> have to copy the entire filesystem to an external drive and ship it, I'll do 
> that, but I'm hoping that some smaller amount of data that I can upload in a 
> few hours would be sufficient.

For that purpose, we have btrfs-image, which will only dump the
metadata, which is way smaller than the full disk, and can be further
compressed using -c9 option. (And you can compress it furthermore).

That btrfs-image dump even contains log tree, which is exactly what we
need to fix the hang.

Thanks,
Qu

> 
> When I write a function that reads a file of a certain format, unless it's a 
> static file like a list of all primes less than 65536 with associated data, I 
> fuzz it so that, if it's given a file that's not exactly in that format, it 
> won't hang or crash.
> 
> Pierre
>