Re: Drive won't mount, please help

Qu Wenruo
2020-09-27T00:13:02Z

[-- Attachment #1.1: Type: text/plain, Size: 6884 bytes --]

On 2020/9/27 上午1:27, J J wrote:
> I ran btrfs-restore and recovered some data, but not most, and not the most critical. Believe it or not, my other backup drive failed within the same week (different file system, different location), so I’m worried I lost a lot of data.
>
> I'm Following this page https://btrfs.wiki.kernel.org/index.php/Restore, is this the best source for information?
>
> find-root command did not help, It showed
> “Well block 11516668403712 seems good”
> but it didn’t show any of the Generation lines to choose from.

In your case, find root won't really help, since it's transid error.

It now mostly depends on pure luck to get some data back.

>
> Any reason to disable the write cache now? Or did you mean for future workaround?

Disabling write cache is for the future.

If it's really the hard disks' problem (especially if both corrupted
drives are the same batch), then it could prevent future problems, not
only for btrfs, but also other fses.

Since the FUA/FLUSH problem is really the core mechanism for all fses to
survive sudden powerloss.

And, if you're not using the same batch of disks, but same RAID
card/controller, then it can be the problem of the RAID card too.
Then I'm not sure disabling write-cache would work for RAID card, but at
least we can try...

>
> Will btrfs-zero-log help?

No. zero-log only works if the fs is still fine, but only log tree is
corrupted.

In your case, your fs is already corrupted, nothing to do with log tree.

>
> How about these?
> • -s: Also restore snapshots. Without this option snapshots will not be restored.
> • -x: Get extended attributes. Without this option, extented attributes will not be retrieved.
> • -m: Restore metadata: owner, mode and times.
>
> Should I move on to this advice? from https://ownyourbits.com/2019/03/03/how-to-recover-a-btrfs-partition/
>
> If we are still not able to mount normally, we can now run btrfs rescue super-recover, which will try to restore the superblock from a good copy. This is not completely safe.
>
> As mentioned before, if your metadata was corrupt there is a chance that files or part of files that are not damaged are not seen by the filesystem. In this scenario, we can use btrfs rescue chunk-recover /dev/sdXY to scan the whole drive contents and try to rebuild the metadata trees. This will take very long specially for big drives, and could result in some of the data being wrongly restored.

I don't think any of them would help in your case.

Your super blocks are all fine. Thus super-recover won't work.
The problems are the tree blocks, and a lot of your tree blocks write
didn't reach disk properly.

We may enhance btrfs-restore to do full disk scan to try to grab some
valid tree blocks, but that would be a big work in the far future.
Not something can benefit you right now.

So if current btrfs-restore doesn't work well, I'm afraid you really
lost the critical data.
The only thing we can help is to find some potential causes to prevent
such problem from happening again.

Thanks,
Qu

>
> Thank you for your time!!
>
>> On Sep 24, 2020, at 7:14 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2020/9/25 上午6:28, J J wrote:
>>> Thanks for your help Qu.
>>> So is the data lost? Should I follow the procedure to recover what I can to another disk?
>>> Any other suggestions for next steps?
>>
>> btrfs-restore is the normally the tool you need to salvage your data.
>>
>> Thanks,
>> Qu
>>>
>>>> On Sep 14, 2020, at 4:34 AM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2020/9/14 上午4:56, J J wrote:
>>>>> I’m new to a lot of this, just trying to use a NAS at home, single usb external disk, not RAID. Was working great for a few months, I’m not sure what changed today when it stopped mounting. Any advice appreciated.
>>>>
>>>> Transid mismatch, and the expected transid is newer than the on-disk
>>>> transid.
>>>>
>>>> This means, either btrfs has some bug that causes metadata writeback not
>>>> following COW, or the disk controller/disk itself ignores Flush/FUA
>>>> commands.
>>>>
>>>> Considering it's usb external disk, I doubt the later case.
>>>>
>>>> In that case, any fs would experience similar problem if a sudden power
>>>> loss or cable loss happened.
>>>>
>>>> You may workaround such problem by disabling the writecache, but I doubt
>>>> if the USB->Sata convert would follow the request.
>>>>
>>>> Thanks,
>>>> Qu
>>>>>
>>>>> Dmesg log attached
>>>>>
>>>>>
>>>>> uname -a
>>>>> Linux rock64 4.4.190-1233-rockchip-ayufan-gd3f1be0ed310 #1 SMP Wed Aug 28 08:59:34 UTC 2019 aarch64 GNU/Linux
>>>>>
>>>>>
>>>>>
>>>>> btrfs --version
>>>>> btrfs-progs v4.7.3
>>>>>
>>>>>
>>>>>
>>>>> btrfs fi show
>>>>> Label: '3TBRock64' uuid: 71eda2e3-384c-4868-b5d4-683f222865e6
>>>>> Total devices 1 FS bytes used 2.48TiB
>>>>> devid 1 size 2.73TiB used 2.59TiB path /dev/mapper/sda-crypt
>>>>>
>>>>>
>>>>> btrfs fi df /dev/mapper/sda-crypt
>>>>> ERROR: not a btrfs filesystem: /dev/mapper/sda-crypt
>>>>>
>>>>>
>>>>> btrfs inspect-internal dump-super /dev/mapper/sda-crypt
>>>>> superblock: bytenr=65536, device=/dev/mapper/sda-crypt
>>>>> ---------------------------------------------------------
>>>>> csum_type 0 (crc32c)
>>>>> csum_size 4
>>>>> csum 0x9e8b0c33 [match]
>>>>> bytenr 65536
>>>>> flags 0x1
>>>>> ( WRITTEN )
>>>>> magic _BHRfS_M [match]
>>>>> fsid 71eda2e3-384c-4868-b5d4-683f222865e6
>>>>> label 3TBRock64
>>>>> generation 395886
>>>>> root 2638934654976
>>>>> sys_array_size 129
>>>>> chunk_root_generation 377485
>>>>> root_level 1
>>>>> chunk_root 20971520
>>>>> chunk_root_level 1
>>>>> log_root 2638952366080
>>>>> log_root_transid 0
>>>>> log_root_level 0
>>>>> total_bytes 3000556847104
>>>>> bytes_used 2729422221312
>>>>> sectorsize 4096
>>>>> nodesize 16384
>>>>> leafsize 16384
>>>>> stripesize 4096
>>>>> root_dir 6
>>>>> num_devices 1
>>>>> compat_flags 0x0
>>>>> compat_ro_flags 0x0
>>>>> incompat_flags 0x161
>>>>> ( MIXED_BACKREF |
>>>>> BIG_METADATA |
>>>>> EXTENDED_IREF |
>>>>> SKINNY_METADATA )
>>>>> cache_generation 395886
>>>>> uuid_tree_generation 395886
>>>>> dev_item.uuid b7f4386a-18e0-437b-9588-6064ff483fd5
>>>>> dev_item.fsid 71eda2e3-384c-4868-b5d4-683f222865e6 [match]
>>>>> dev_item.type 0
>>>>> dev_item.total_bytes 3000556847104
>>>>> dev_item.bytes_used 2843293515776
>>>>> dev_item.io_align 4096
>>>>> dev_item.io_width 4096
>>>>> dev_item.sector_size 4096
>>>>> dev_item.devid 1
>>>>> dev_item.dev_group 0
>>>>> dev_item.seek_speed 0
>>>>> dev_item.bandwidth 0
>>>>>
>>>>>
>>>>> dev_item.generation 0
>>>>>
>>>>
>>>
>>
>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]