Re: need help in a broken 2TB BTRFS partition

[Qu Wenruo <wqu@suse.com>]

On 2021/10/17 01:35, Christian Wimmer wrote:
> BTW, due to some unsuccessful boot attempts this disc /dev/sdd1 does not work any more with “-o ro,rescue=all”
> so I decided to try some nasty commands like the following:

Well, any attempt to do any write into that fs would only further 
degrade the fs.

> 
> 
> Suse_Tumbleweed:/home/proc # btrfs rescue chunk-recover /dev/sdd1
> Scanning: 4914069504 in dev0cmds/rescue-chunk-recover.c:130: process_extent_buffer: BUG_ON `exist->nmirrors >= BTRFS_MAX_MIRRORS` triggered, value 1
> btrfs(+0x1a121)[0x55830a51d121]
> btrfs(+0x508dc)[0x55830a5538dc]
> /lib64/libc.so.6(+0x8db37)[0x7fa8984cbb37]
> /lib64/libc.so.6(+0x112640)[0x7fa898550640]
> Aborted (core dumped)
> 
> Unfortunately the program crashes. Is this expected?

No, but it doesn't matter anymore.

The problem would not be chunk tree related afaik.

> 
> What else can I try if the mount command reports:
> 
> Suse_Tumbleweed:/home/proc # mount -o ro,rescue=all /dev/sdd1 /home/promise2/disk3
> mount: /home/promise2/disk3: wrong fs type, bad option, bad superblock on /dev/sdd1, missing codepage or helper program, or other error.

Dmesg would provide the reason why it fails to mount.

Thanks,
Qu

> 
> 
> 
> 
> 
>> On 16. Oct 2021, at 07:08, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2021/10/16 05:01, Christian Wimmer wrote:
>>> Hi Qu,
>>>
>>> I hope I find you well.
>>>
>>> Almost two years that my system runs without any failure.
>>> Since this is very boring I tried make my life somehow harder and tested again the snapshot feature of my Parallels Desktop installation yesterday:-)
>>> When I erased the old snapshots I could feel (and actually hear) already that the system is writing too much to the partitions.
>>> What I want to say is that it took too long (for any reason) to erase the old snapshots and to shut the system down.
>>
>> The slow down seems to be caused by qgroup.
>>
>> We already have an idea how to solve the problem and have some patches
>> for that.
>>
>> Although it would add a new sysfs interface and may need user space
>> tools support.
>>
>>>
>>> Well, after booting I saw that one of the discs is not coming back and I got the following error message:
>>>
>>> Suse_Tumbleweed:/home/proc # btrfs check /dev/sdd1
>>> Opening filesystem to check...
>>> parent transid verify failed on 324239360 wanted 208553 found 184371
>>> parent transid verify failed on 324239360 wanted 208553 found 184371
>>> parent transid verify failed on 324239360 wanted 208553 found 184371
>>
>> This is the typical transid mismatch, caused by missing writes.
>>
>> Normally if it's a physical machine, the first thing we suspect would be
>> the disk.
>>
>> But since you're using an VM in MacOS, it has a whole storage stack to
>> go through.
>>
>> And any of the stack is not handling flush/fua correctly, then it can
>> definitely go wrong like this.
>>
>>
>>> Ignoring transid failure
>>> leaf parent key incorrect 324239360
>>> ERROR: failed to read block groups: Operation not permitted
>>> ERROR: cannot open file system
>>>
>>>
>>> Could you help me to debug and repair this please?
>>
>> Repair is not really possible.
>>
>>>
>>> I already run the command btrfs restore /dev/sdd1 . and could restore 90% of the data but not the important last 10%.
>>
>> Using newer kernel like v5.14, you can using "-o ro,rescue=all" mount
>> option, which would act mostly like btrfs-restore, and you may have a
>> chance to recover the lost 10%.
>>
>>>
>>> My system is:
>>>
>>> Suse Tumbleweed inside Parallels Desktop on a Mac Mini
>>>
>>> Mac Min: Big Sur
>>> Parallels Desktop: 17.1.0
>>> Suse: Linux Suse_Tumbleweed 5.13.2-1-default #1 SMP Thu Jul 15 03:36:02 UTC 2021 (89416ca) x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> Suse_Tumbleweed:~ # btrfs --version
>>> btrfs-progs v5.13
>>>
>>> The disk /dev/sdd1 is one of several 2TB partitions that reside on a NAS attached to the Mac Mini like
>>
>> /dev/sdd1 is directly mapped into the VM or something else?
>>
>> Or a file in remote filesystem (like NFS) then mapped into the VM?
>>
>> Thanks,
>> Qu
>>
>>>
>>> Disk /dev/sde: 2 TiB, 2197949513728 bytes, 4292870144 sectors
>>> Disk model: Linux_raid5_2tb_
>>> Units: sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 4096 bytes
>>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>>> Disklabel type: gpt
>>> Disk identifier: 942781EC-8969-408B-BE8D-67F6A8AD6355
>>>
>>> Device     Start        End    Sectors Size Type
>>> /dev/sde1   2048 4292868095 4292866048   2T Linux filesystem
>>>
>>>
>>> What would be the next steps to repair this disk?
>>>
>>> Thank you all in advance for your help,
>>>
>>> Chris
>>>
>