Re: Drive won't mount, please help

J J
2020-09-26T17:27:30Z

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.

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

Will btrfs-zero-log help?

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.

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
>>>>
>>>
>>
>