Moving parity drives from external USB to (shucked) internal SATA

[-C-]

I put Unraid together on an old Thinkserver with the array's 4 data drives connected via SATA and the 2 x 20TB parity drives in their USB enclosures due to lack of power/ drive bays.

 

Now I've built a new system in a bigger box and power supply with enough SATA power connections, I have shucked the 20TBs from their cases and put them inside. The problem is that Unraid's now seeing them as different drives. As rebuilding parity on these big drives takes so long, I'd like to avoid that.

 

I've read https://wiki.unraid.net/Manual/Tools#New_Config which seems to be about reassigning the data drives rather than parity. It does say:

"It exploits the fact that Unraid can recognise drives that have previously been used by Unraid and will leave their contents untouched (as long as the drive is not assigned as a parity drive)."

 

But I'm not sure it's addressing my situation.

 

The other possible issue I have is that I was not expecting this so did not make a note of which drive was which. I am now not sure which new drive ID marries up with the old USB one. Will this be an issue considering that the data on both parity drives should be identical?

 

Can I avoid rebuilding parity?

[Frank1940]

This may help you with some of your questions:

 

 

[JorgeB]

New config might work or not depending on the enclosures used, some USB enclosures don't have a transparent USB bridge, i.e. the data will be completely different without it.

 

24 minutes ago, -C- said:

Will this be an issue considering that the data on both parity drives should be identical?

This would be an issue, parity2 is calculated in a different way, so they are not interchangeable.

[Kilrah]

You can do a New Config, assign both drives, start the array with "Parity is already valid", then start a parity check without "Write corrections to parity" checked, and look at the number of errors. If it climbs like crazy stop the operation and array, new config again, swap the 2 drive assignments, do the same... If either of these goes with no parity errors you're most likely good. If not you'll have no choice but to rebuild parity.

 

Do note that for parity2 to be valid all data drives need to be assigned to the same slots as before too. 

Edited December 19, 2022 by Kilrah

[-C-]

Have found that the s/n of the bare drive that Unraid is now detecting matches with the s/n printed on the USB case. I kept the USB controller PCBs inside the cases that they came from, so I'm going to temporarily put one of the drives back in its case, let Unraid see it and from here can see which is which.

 

Once I've figured out which way round the parities go, is there a way to reassign them?

[-C-]

48 minutes ago, Kilrah said:

You can do a New Config, assign both drives, start the array with "Parity is already valid", then start a parity check without "Write corrections to parity" checked, and look at the number of errors. If it climbs like crazy stop the operation and array, new config again, swap the 2 drive assignments, do the same... If either of these goes with no parity errors you're most likely good. If not you'll have no choice but to rebuild parity.

 

Do note that for parity2 to be valid all data drives need to be assigned to the same slots as before too. 

Apologies didn't refresh my page and see this before writing my previous post.

 

So I've now got a (hopefully) surefire way of IDing the drives, so my course of action once I've done that is to:

1. Assign the correct parity drive to its correct slot
2. New Config, start the array with "Parity is already valid"
3. Start a parity check without "Write corrections to parity" checked
4. Hope that this checks out, if not rebuild parity
5. If it checks out I'm good to go.

Out of interest, how does the time to check parity compare with the time to rebuild it?

[JorgeB]

14 minutes ago, -C- said:

how does the time to check parity compare with the time to rebuild it?

It's basically the same if there are no or few sync errors, much slower if there are many, in that case cancel and do a sync.

[-C-]

I hadn't realised that the New Config tool was going to completely deassign all drives as soon as I clicked that button- I assumed I was going to be taken to some options where I could choose which drives I wanted change.

 

Now all my drives are unassigned and I'm not sure which slots they were in. What's my best course of action from here?

I have an backup of my system USB drive from about 3 weeks ago saved locally- I'm fairly sure all the drives had been put into their correct slots by then, but not certain.

I have the My Servers backup set up, but the only option I see is to 'Generate Flash Backup' with a timestamp that looks like it's after I ran New Config. Is it possible to download an older backup from there (that's more recent than the one I have saved locally)?

If the My Servers backup isn't going to be an option, rather than restoring the old backup I have and losing all the work I've done setting things up since then, is there a way to extract a config file from my local backup .zip that'll show me which drive was in which slot?

 

I have also saved the syslog that covers since I booted Unraid, before I did the New Config. I can see these lines in it per drive. This is an example of an array data drive. Anything useful?

Dec 19 16:02:40 Tower kernel: scsi 6:0:0:0: Direct-Access ATA ST6000DX000-1H21 CC48 PQ: 0 ANSI: 5 
Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: Attached scsi generic sg6 type 0 
Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: [sdg] 11721045168 512-byte logical blocks: (6.00 TB/5.46 TiB) 
Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: [sdg] 4096-byte physical blocks Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: [sdg] Write Protect is off 
Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00 
Dec 19 16:02:40 Tower kernel: sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[Kilrah]

Well there was the "Preserve assignments" choice to make before going ahead and confirm you really want...

 

If you have your syslog you can see the assignments a couple of minutes after boot:

 

[-C-]

Ah, I see now- this is what it looks like for me:

 

It was not at all clear that was a dropdown or an option I could change. A box around it or, better yet, Radio buttons would make things more obvious here.

 

Thanks- I've found that part of the log and can now reassign all the drives.

[-C-]

All ready to start the array again, I've checked the Parity is already valid box, but I'm stuck at this point:

 

Start a parity check without "Write corrections to parity" checked

 

I don't see that option- where do I find it?

[itimpi]

2 minutes ago, -C- said:

Start a parity check without "Write corrections to parity" checked

 

I don't see that option- where do I find it?

That will only be available after you have started the array.

[Kilrah]

2 hours ago, -C- said:

Ah, I see now- this is what it looks like for me:

Must be something with the theme you're using:

 

[-C-]

Thank you all for your help.

 

The parity check's been running for > 2 hours now and we have zero errors, so things look like they've gone well.

 

Special thanks to @Kilrah - that last screen grab was super helpful. I am running a Firefox add-on that turns light websites into dark mode, which normally works well, but sometimes gets things wrong or misses page elements. That was the cause of the dropdown not displaying correctly. I've now disabled that add-on for my Unraid, used Unraid's display settings to set things up how I like, now my dropdown looks the same as yours. This could well have been causing me issues with other pages, so I'm glad I've got that sorted.

[-C-]

Parity check's just finished, but with 2 errors:

 

Write corrections to parity was checked during this. Any reason for concern, or am I OK to consider parity's good now?

 

[trurl]

A non-correcting parity check to confirm there are no sync errors now. If you have one scheduled soon you could wait on that.

[-C-]

Just got back from xmas break (haven't managed to get Wireguard working yet) and this was the non-correcting parity check's result:

 

 

[trurl]

post new diagnostics

[-C-]

Attached, thanks

tower-diagnostics-20221229-1333.zip

[trurl]

You should correct those 2 sync errors.

[-C-]

5 hours ago, trurl said:

You should correct those 2 sync errors.

I'd originally done a correcting parity sync and got this result:

 

Then was advised to do a non-correcting that finished on the 25th with 2 errors.
 

Won't running a correcting parity check again be doing the same as the one that completed on the 21st?

[trurl]

Do you have diagnostics or syslog from that earlier correcting parity check? The later non-correcting check says you still have sync errors.

[trurl]

Found these from the non-correcting check.

Dec 25 11:04:38 Tower kernel: md: recovery thread: PQ incorrect, sector=39063584664
Dec 25 11:04:38 Tower kernel: md: recovery thread: PQ incorrect, sector=39063584696

We would need to compare to the correcting check. Currently have no evidence a correcting check was done.

[trurl]

1 hour ago, trurl said:

Currently have no evidence a correcting check was done.

Since you have parity check tuning installed, maybe it will show us more.

 

Go to Main - Array Operation, click History, post a screenshot

[-C-]

Here it is:

 

As both of the last ones are showing as Parity-Check, it looks like I didn't do a Sync as intended.

Is a parity sync achieved by keeping the "Write corrections to parity" checked before clicking the Check button? (I thought that's what I'd done when I ran the one that ended on the 21st).