Hardware Build - then rebuild

[Wizengamot]

I have initially deployed my UnRaid (v. 6.8.1) array (using a trial key) using 10 x 8TB disks.  (IronWolf if it matters).  2 disks are parity, the rest are disks 1 thru 8.  My main board is an ASUS TUF B450 with a Ryzen 3 3200G processor and 8GB of DDR4 RAM.  Currently I am using an LSI 9201 - 8i card for 8 of the drives and the main board SATA connectors for the remaining two.  My plan is to migrate this setup to a new drive controller.  The new controller is a LSI 9201 16E card and the drive chassis is a NetApp 4243 that allows 24 HDDs to be inserted.

 

Assuming that the hardware works, does anyone know of any Gotchas when moving the drives? I assume that their OS designations will change, but obviously the serial numbers will NOT change.  Will the system automatically find serial number X at whatever OS designation (sdb, sdc sdd, etc) and assign it to the correct location in the array?  Will a rebuild be required?  I have chosen the system to use BTRFS as the filesystem and I chose this prior to formatting the array.

 

If there is not anyone who has tried something similar before I will be posting my results back here so that we add to the community.  I did do some searching before posting and could not find anything, but if you know of a post that is similar to mine, I would be most interested to read it.  Thanks in advance!

 

[JorgeB]

There won't be any problems unless the NetApp changes the disk ID strings, never used one but IIRC it might.

[Wizengamot]

4 hours ago, johnnie.black said:

There won't be any problems unless the NetApp changes the disk ID strings, never used one but IIRC it might.

I can probably say for sure that the disk id strings will change.  That is, unless the OS stores them on the disk itself and retrieves them on boot.  I do not know whether this occurs or not.

 

What kind of problems can I expect? 

 

I know that if I did this same procedure with ZFS I would not have any problems.  I have intentionally taken disks out of ZFS and then put them back in the enclosure in a different order to ensure that the OS will assign a new id to it, and ZFS doesn't care.  At the worst it would resilver...  BUT, the best implementation of ZFS I can find is FreeNAS and the sharing on that system sucks compared to what I have found with UnRaid.

 

If the worst is that UnRaid will do a parity rebuild (which based on what I can find out is the same as a resilver in FreeNAS), then I won't worry too much.  But if changing the disk id strings could in effect lose all the data, it worries me greatly.

[JorgeB]

8 minutes ago, Wizengamot said:

That is, unless the OS stores them on the disk itself and retrieves them on boot.

They are not stored, sdX can and will change and that's not a problem, but if the disk id string changes (model + serial) Unraid will consider it's a different disk and complain, by id sting I mean just the highlighted part:

 

 

This can change with RAID controllers, USB enclosures and some DAS enclosures, but like I mentioned I'm not sure the NetApp changes that as I never used one, it's easy to try and check.

 

 

[Wizengamot]

12 hours ago, johnnie.black said:

They are not stored, sdX can and will change and that's not a problem, but if the disk id string changes (model + serial) Unraid will consider it's a different disk and complain, by id sting I mean just the highlighted part:

 

 

This can change with RAID controllers, USB enclosures and some DAS enclosures, but like I mentioned I'm not sure the NetApp changes that as I never used one, it's easy to try and check.

 

 

Thanks very much for the clear explanation.  I understand what to test now and I greatly appreciate the time and attention.

[Wizengamot]

I have finally been able to test the disk id strings between the motherboard SATA connectors and the NetAPP device connected via SAS cable to the same computer running unRAID.  The test disk showed up as per PIC1 below, and the same disk showed up as per PIC2 below when connected via the NETAPP device.  It looks like the SATA controller method via the motherboard appends the WDC_ to the front of the disk id.

 

Does anyone know of a way where I can move the disk from one location to another and inform unRAID that even though the disk id changed, that disk 8 is in fact a specified disk regardless of the disk id?

 

Is there a way where I can assign the disk ids myself rather than let unRAID do this for me?  Would this be a feature request for advanced users?

 

I will test one the Ironwolves next to see if they behave the same way, but I expect they will.

 

I do have a backup of the configuration as well as a full screenshot of the disk ids as they exist now.

 

EDIT:

Looks like the Ironwolves behave the same way.  The disk id when connected to the array starts with ST8000VN0022-

but when connected to the 9201-16i via SAS the disk id starts with 0022.

 

I suppose I could move one disk at at time and rebuild the array until all 10 drives are moved, but 10 rebuilds would be very hard on the drives.  It might be cheaper to get a second computer and transfer the data to different disks in a new unRAID.  Yes, I have enough disks and capacity from the old FreeNAS to do this, but I was hoping to NOT do a second data copy if I could avoid it.  

 

Any other ideas on how to resolve this would be greatly appreciated.  Maybe we can get 6.8.2 released with a patch for resolving disk ids without overwriting the target disk. (While I am a dev, the above may be a huge amount of work, I really don't know as I don't know the unRAID code base)

Edited February 15, 2020 by Wizengamot
new information

[JonathanM]

1 hour ago, Wizengamot said:

 

Is there a way where I can assign the disk ids myself rather than let unRAID do this for me?

Tools, New Config, preserve all, then go to the Main tab and carefully replace the slots with the correct disks. As long as parity was valid when the array was stopped, and the disks have not been mounted since, you can select the "parity is already valid" option and just do a parity check.

[Wizengamot]

Thanks!  I will give this a go today and report back.  I started a brand new parity check yesterday that I need to let complete before I attempt this.  That way I'll have a fresh parity check to work with.

 

Results:

I was able to follow these instructions.  Hint for some newbie trying this.  The Parity Is Already Valid checkmark is a bit small and buried in the text to the right of the start array buttons.  

One thing to note.. The write-up on the New Configuration screen makes it sound like you will lose data but IF you check off the "preserve all" in the dropdown you won't lose data IF you know exactly which serial number drive goes where in your array of disks.

Edited February 17, 2020 by Wizengamot
Posting Results