(SOLVED) best practices reordering disks

[tillkrueger]

I've spent the past 10 days moving data from my oldest 2TB disks onto my newer larger drives, which I emptied and converted to XFS before moving data onto them...quite a tedious and lengthy process...I now have enough XFS formatted drives to hold *all* of my data (21TB with 19.4TB of data), with another 17TB total in smaller/older disks, most of them either reiserfs and/or empty.

I want to go to the server's location today and physically reorder the drives...I have a few questions regarding best practices:

> can I just stop the array, reorder the drives, reassign the drives in the new order, and start the array again, since nothing else changed, data-wise?
> or do I need run "New Config" first and run a parity check again?
> once everything is in its proper order, I will probably shuffle data some more until they are all XFS formatted with a good amount of free space left and remove the 3 or 4 oldest 2TB drives...at that point I will definitely have to do "New Config" and redo parity, no?

thanks in advance for your advice/clarification. 

[JorgeB]

19 minutes ago, tillkrueger said:

> can I just stop the array, reorder the drives, reassign the drives in the new order, and start the array again, since nothing else changed, data-wise?

 

Assuming single parity, yes and no, you can re-order the data disks but since v6.2 it's not possible to start the array after doing that, you'll still need to do a new config but you can check "parity is already valid" to avoid a new parity sync.

 

22 minutes ago, tillkrueger said:

> once everything is in its proper order, I will probably shuffle data some more until they are all XFS formatted with a good amount of free space left and remove the 3 or 4 oldest 2TB drives...at that point I will definitely have to do "New Config" and redo parity, no?

 

Yes, and this time you'll need to re-sync parity.

 

[tillkrueger]

ok, I'll start with the first part and then plan for the second part...I am sure there'll be more questions in the process, but thanks for the quick answers!

[tillkrueger]

well, I proceeded as discussed, reassigned the drives, started the array with Parity check disabled and it all looks fine, except for this error that Fix Common Problems alerted me of:
 

Call Traces found on your server

Your server has issued one or more call traces. This could be caused by a Kernel Issue, Bad Memory, etc. You should post your diagnostics and ask for assistance on the unRaid forums

what's the best way to proceed from here? it suggests posting Diagnostics results to the forum, but which diagnostics is it suggesting?

[JorgeB]

4 minutes ago, tillkrueger said:

You should post your diagnostics

 

Tools -> Diagnostics

Edited September 18, 2017 by johnnie.black

[tillkrueger]

ah, ok. here they are.
should I start a new thread for this?

unraid-diagnostics-20170918-1445.zip

[JorgeB]

Call traces ae related to the SASLP, there are know issues with those controllers and unRAID v6 and they should be avoided, LSI controllers are recommended.

[tillkrueger]

yeah, it even mentioned that in Fix Common Problems, but I wasn't sure whether that's really what this error what this error was referring to...since these controllers have been doing their job alright all these years, I guess I'll acknowledge/ignore this alert until I can come up with the budget to do the hardware upgrade that I've been hoping to be able to do this year or next.

thanks for confirming! 

[ugachmaaz]

I'm running 6.4.0, and it seems unraid now detects the reordered disks automatically. The disk identifiers (sda, sdb, etc) have changed, but it would seem that unraid pairs the parity and data disks to their serial numbers automatically, without having to create a new config or rebuilding Parity 2.

[bonienl]

1 minute ago, ugachmaaz said:

I'm running 6.4.0, and it seems unraid now detects the reordered disks automatically

 

unRAID is doing this since version 5, it is not something new in 6.4 or later.

[ugachmaaz]

1 minute ago, bonienl said:

 

unRAID is doing this since version 5, it is not something new in 6.4 or later.

 

In that case, I may have misunderstood the advice on a couple of threads. Some of these threads indicate that Parity 2 may need to be rebuilt, and would have to accept Parity 1 as valid. 

[bonienl]

There is a difference between single and dual parity.

 

Dual parity was introduced in unRAID 6.2 and the second parity disk (parity2) relies on the disk order. When changing the disk order (e.g. disk1 becomes disk2) it will invalidate parity2.

Single parity systems don't need a fixed order, and parity stays valid when the order is changed.