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 >
Attachment:
signature.asc
Description: OpenPGP digital signature
