I am about to start upgrading drives on my server. Really critical as I have a drive failing.

 

My current plan is to get a new 6tb and make that the new parity. Then take the old parity and replace the dying drive with it.

 

When I built the system the drives were installed somewhat ad-hoc.

The question: can I change the controllers (and physical locations) of the drives to 'rationalize' them for future upgrades?

 

For example I have a 4 in 3 chassis that I would like to move my 4 smallest drives into, so that as I get new 6tb drives I would not have to open up the system completely. Then once those 4 are upgraded, swap them to the 'bottom' of the internal stack and move the next 4 smallest to the front mount chassis.

 

Obviously I plan on carefully noting both the sd# <-> drive mapping and then mapping the physical controller <-> drive to know which is where.

 

Is this an insane idea, or doable but not a good idea, or is it a smart thing to do?

 

Thanks!

I am about to start upgrading drives on my server. Really critical as I have a drive failing.

 

My current plan is to get a new 6tb and make that the new parity. Then take the old parity and replace the dying drive with it.

 

When I built the system the drives were installed somewhat ad-hoc.

The question: can I change the controllers (and physical locations) of the drives to 'rationalize' them for future upgrades?

 

For example I have a 4 in 3 chassis that I would like to move my 4 smallest drives into, so that as I get new 6tb drives I would not have to open up the system completely. Then once those 4 are upgraded, swap them to the 'bottom' of the internal stack and move the next 4 smallest to the front mount chassis.

 

Obviously I plan on carefully noting both the sd# <-> drive mapping and then mapping the physical controller <-> drive to know which is where.

 

Is this an insane idea, or doable but not a good idea, or is it a smart thing to do?

 

Thanks!

 

Yes you can do that. The critical thing you need to keep in mind is the drive serial numbers. You want a list of the assignments and serial numbers (What is your Parity, what is assigned as Drive 1, ect.) so that you can properly reassign them.

A few thoughts:

 

- Be very careful with the failing drive.  If you go forward with your plan to upgrade parity before replacing the failing drive you could easily experience a complete failure on that drive during the stress of the parity sync.  Dealing with the failing drive first is advisable.

 

- unRAID 5 and 6 identify drives by serial number.  You can move drives around to different controllers and physical locations, and as you do the sdX device ID will change.  That's Ok since unRAID is using the serial number to positively identify the disk.

 

- There's a server layout plugin that you might want to look into to help document everything.

A few thoughts:

 

- Be very careful with the failing drive.  If you go forward with your plan to upgrade parity before replacing the failing drive you could easily experience a complete failure on that drive during the stress of the parity sync.  Dealing with the failing drive first is advisable.

 

- unRAID 5 and 6 identify drives by serial number.  You can move drives around to different controllers and physical locations, and as you do the sdX device ID will change.  That's Ok since unRAID is using the serial number to positively identify the disk.

 

 

- There's a server layout plugin that you might want to look into to help document everything.

 

Thanks!

 

First thing I'll do is get the plugin run.

 

since I have an unused 1.5 or 2tb drive, I can just do a swap with the dying drive.

 

And I realize that I have a clarification needed. once I move the drives to their "rational' physical locations, I need to put them logically in the same drive number location they were in before:

 

i.e. Drive 1 is a WD on sdc and drive 2 is a seagate on sdd(using brand instead of serial).

once I move the physical locations the WD thinks it is sdh but needs to be put in Drive 1 and the seagate, as with the WD goes in the drive 2 slot, regardless of its sd(?).

 

You don't have to worry about putting the drives into the same slots, or worry about the sdX device IDs.  In fact, you should be able to shut down the box, switch some drives around, and boot again - unRAID (from version 5 forward) should recognize the drives automatically - no intervention required on your part.  For instance - the drive in slot 1 may be WDC000000123456 (sda) before you re-arrange, and afterwards WDC000000123456 may become (sdb) - but unRAID 5+ keeps track of the fact that 123456 is a data drive and which slot it is in.

 

That said - be very careful to note the serial numbers of your parity drive and cache drives.  You don't want to mix those up with data drives!  The data drives can be assigned to slots in any order.

 

You may be remembering the unRAID 4.x days - it was very important to track devices and slots, etc. with older versions of unRAID.

...And I realize that I have a clarification needed. once I move the drives to their "rational' physical locations, I need to put them logically in the same drive number location they were in before:

 

i.e. Drive 1 is a WD on sdc and drive 2 is a seagate on sdd(using brand instead of serial).

once I move the physical locations the WD thinks it is sdh but needs to be put in Drive 1 and the seagate, as with the WD goes in the drive 2 slot, regardless of its sd(?).

As far as unRAID is concerned, whatever serial number currently assigned to drive 1 will be drive 1 regardless of what bay it is in or what port it is plugged into or what sdX it winds up being. You don't need to do anything to make it drive 1.

 

I have moved to a new case or a new motherboard and unRAID just started up as if nothing had happened, including which drive was assigned to which slot.