I recently had my parity drive go bad. So set about replacing it.

 

When I re-powered the server I started getting CRC errors of Drive 5 and Drive 6, which obviously led to a parity sync fail. 

 

I powered down and replaced the sata cables on those drives. By this point Drive 6 had gone disabled and I can't get it back. It passes a short SMART test.

 

Researching on the forum I see this situation has been encountered before so I wanted to do a xfs file system check, however it instantly results in a "superblock read failed"

 

I'm currently using ddrescue to clone Drive 6 to another drive that is outside the array (that has been pre-cleared). 

 

Can someone advise me of the next steps once ddrescue has finished its process?

 

Is there a chance I can repair Disk 6 in situ without having to copy back data from ddrescue destination disc?

 

Diagnostics attached.

 

Thanks in advance to this great community!

tower-diagnostics-20241009-1148.zip

Since there are two invalid disks, disk6 cannot be emulated, do a new config and it will re-enable the disk, but it has a pending sector, so you should run an extended SMART test before trying to sync parity again.

Thank you for the reply @JorgeB

 

I will let ddrescue complete then reboot and do a new config and report back after an extended SMART test. 

1 hour ago, air_marshall said:

I will let ddrescue complete

If ddrescue doesn't show any read errors, you can do without the SMART test for now, since it will read the whole disk.

ddrescue completed without error, took a while as everytime the console closed it seemed to stop. anyway, handy that it can resume.....

 

I mounted the destination drive and the data is present and readable.

 

How can I check the data on disc 6 is identical to the ddresuce copy to destination? Some sort of checksum comparison process/tool?

 

I didn't see your message so the extended SMART check was run on disc 6, it passed without error.

 

Following the new config the array is now back up and parity is being created. Diagnostics attached.

 

 

tower-diagnostics-20241010-2028.zip

12 hours ago, air_marshall said:

How can I check the data on disc 6 is identical to the ddresuce copy to destination?

If there weren't any errors during the copy it should be 1:1 identical

nas42-diagnostics-20260728-2222.zip

@Ellol

Please describe your problem.

Hi, sure, sorry, looks like I managed to delete the text 🤦

I was trying to convert my 10+ years old machine to a NAS but the hardware proves unreliable by now and one of my array HDDs ('Unmountable: wrong or no file system') and the sole parity drive (listed as unassigned disk device with the 'Mount' button available ) dropped off. Took a look at them under Win11, connected through an external HDD case, hoping to retrieve the data from the array drive (tried with Linux File Systems for Windows by Paragon Software as it's read-only for BTRFS so no harm expected). They're shown ok in the disk manager, passed the quick smart check via HDSentinel, also tried to mount them on a Mint VM and met the superblock read error and being less savvy at Linux commands than a trained monkey with a keyboard I just don't dare to follow the AI or to take any other action from this point. Not even sure which disk I'd have better chances with and while I'd love the simplicity of reassigning the parity drive - just came to my mind reading this post above - and trust that exact drive more ( few months old WD Red Pro vs a WD Red Plus over 5 yrs ) but seems a long shot to me. May I ask for your advice how you'ld resolve this, please? Thank you very much in advance.

Jul 28 22:19:36 Nas42 kernel: BTRFS error (device md3p1): parent transid verify failed on logical 3206967361536 mirror 1 wanted 25295 found 23043

Jul 28 22:19:36 Nas42 kernel: BTRFS error (device md3p1): parent transid verify failed on logical 3206967361536 mirror 2 wanted 25295 found 23043

This is typically fatal with btrfs, it means some writes to the disk were missed, and both metadata copies agree; typically this means the controller/disk firmware lied and reported they were done and safely saved on the actual disk, not in flight, when they were not.

Though you may still be able to mount the disk read only or use btrfs restore to recover some/all data:

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-543490

Thank you very much, @JorgeB , will follow the steps there and confirm back.

Any hope for the parity drive perhaps or is it gone, awaiting to get formatted and reused?

You can read parity, but it won't be 100% in sync, and will likely not help if you try emulating that disk, but you can try if you like:

-Tools -> New Config -> Preserve current assignments: All -> Apply

Assign parity, check "parity is already valid", start the array, stop the array, unassign disk3, start the array and see if the emulated disk3 mounts.

If it fails to mount, and it most likely it will, you can do a new config again, reassign dsk3, trust parity, then run a correcting parity check to avoid a full sync, since it should be mostly valid.

thank you so much, I'll try that as well