Re: Filesystem Degradation and transid Verification Failure

On 2021/10/3 10:55, dmzlaamx@gmail.com wrote:

On 2021/10/3 13:23, quwenruo.btrfs@gmx.com wrote:

quoted

On 2021/10/2 19:20, dmzlaamx@gmail.com wrote:

quoted

Hello,
I must preface this by saying I have never used a mailing list before
so please forgive any lack of understanding of the protocols and standards.

I have been having a lot of trouble attempting to recover the
filesystem on a single 6TB disk. The drive can be mounted, but certain
folders return “Input/output error” when attempting to access them.

The error is caused by transid, and according to the expected transid, it's a missing write.

This seems to happen either you have mounted with "nobarrier" mount option, or the device has non-reliable firmware handling FLUSH/FUA commands.

In above cases, a power loss can lead to such problem.

A power loss is what I assumed, interesting to see that it's very likely the cause.

quoted

Mind to share the hardware model and firmware version?
We're trying to collect such known bad HDDs.

The disk model number is ST6000VN0041-2EL
The disk firmware version is SC61

quoted

quoted

I have attempted btrfs check, recover, restore, and rescue, and have
managed to recover some of the data – although the folders which
presented issues have not been recovered.
Btrfs restore returns transid errors even with alternate roots.

I want to run btrfs check --repair,  but before that I want to check
if there’s anything else I should do before resorting to that.

Supplementary info
	uname:		Linux eros-station 5.12.9-arch1-1 #1 SMP PREEMPT
Thu, 03 Jun 2021 11:36:13 +0000 x86_64 GNU/Linux
	Btrfs version:	btrfs-progs v5.14.1

The results from the two other btrfs commands are attached, including
the first few hundred lines from dmesg.

Should I attempt repairing the filesystem, or are there other options
I should try first?

No much thing can be done if you have already tried btrfs-restore and got nothing you want.

Does this mean that I can/should proceed with btrfs check --repair?

Yes, as I don't believe there is much thing can be done.

I'm afraid btrfs check --repair won't bring much help either.

Or is the data totally and completely unrecoverable, even by a data recovery company?

The data may not be fully destroyed, but we lost the metadata to reach them.

Not familiar with data recovery company, especially not sure if they are
familiar with btrfs enough.

But I assume if they take the full binary dump, and can do a full
metadata scan, they may or may not recovery some older metadata to reach
part of the data.

Just wondering how screwed I am.

Not your fault, but more like the fault of your HDD vendor.

Thanks,
Qu

quoted

If you still plan to use that HDD, then we recommend to disable write cache:
https://btrfs.wiki.kernel.org/index.php/FAQ#I_see_a_warning_in_dmesg_about_barriers_being_disabled_when_mounting_my_filesystem._What_does_that_mean.3F

Alright, this does seem like an important thing to do.

quoted

Thanks,
Qu

quoted

Thank you