I want to move 2 disks to different slots and add two new ones in their places. I unassigned them in the devices, powered down, then moved them. When I assigned them to the other disks, it says missing disks. Disk 5 is now disk 9 and disk 7 is now disk 8. The disks that say are missing, I plan on adding new disks there, but I want to make sure the current disks are correct before doing so.

I am using version 4.7 Pro.

 

Thanks,

Austin

Here is the System Log. I had to put the device arrangement back to the way it was to be able to get the system log. Not sure if that changes anything.

syslog.txt

There is nothing wrong with unRAID, it is behaving exactly as it was designed. 

 

I don't know your motive for wanting to move those disks to a different assigned slot, but as far as unRAID is concerned those disks no longer exist.  If you want to move them to a different slot, you will have to run "initconfig" from the command line and then answer "Yes" to the question.  This will tell unRAID to reset the disk assignments and record the new positions.  After doing this you will have a parity build (I think it is a build and not a check) start so that everything gets updated on the parity drive.

The reason why I want to move them is because I want to keep the related disks next to each other.

The reason why I want to move them is because I want to keep the related disks next to each other.

 

Fair enough. It is not really needed from unRAID's standpoint but if you want to do that just realize that every time to go to rearrange your disks you are going to need to run initconfig from the command prompt or through a telnet session to reset the unRAID disk assignments.  If you are running the 5.0bX version there is a "New Config" button that can be pressed to do the same thing.

Thanks for your help and quick replies!

You actually can exchange two slots and start the array. Might take several stops and starts to get where you want to be.

I thought one of the newer versions of unRAID looked at the HDD's serial number and you could move drives to whatever slot you wanted and the system would recognise the change?

I thought one of the newer versions of unRAID looked at the HDD's serial number and you could move drives to whatever slot you wanted and the system would recognise the change?

True, but obviously he is not on that version.

I thought one of the newer versions of unRAID looked at the HDD's serial number and you could move drives to whatever slot you wanted and the system would recognise the change?

True, but obviously he is not on that version.

 

I don't think so.  What the new version will do is automatically assign disks to the right slot by looking at the drive serial numbers.  That allows you to attach the drives to differnt controllers / ports without having to reassign each disk to the right slot.

So upgrading to 5.0 will make this process easier/better?

So upgrading to 5.0 will make this process easier/better?

yes.  but be aware, although reasonably stable, it is still beta.

 

So upgrading to 5.0 will make this process easier/better?

 

I'm quite certain it will not. The new version does a better job at recognizing the hard drive and keeping it assigned to the disk slot when the SATA port the hard drive was connected to has changed (due to moving it to another drive bay, adding a controller card, changing motherboards, etc). In 4.7 and older versions, unRAID would show the disks as all missing or replaced if you changed around the hardware and you then had to use the devices page and straighten them out. In the newer 5.0b series, unRAID will do a better job of keeping the disks assigned when you change around the hardware. It's a nice feature that was added, however, it has nothing to do with moving a hard drive to another disk assignment on the main unRAID web page.

 

I also believe you can re-arrange disks without invalidating parity but you can only re-arrange disks between locations that are already assigned. In other words, you can swap 2 disks on the main page but you can not swap 1 disk and a blank location. So, moving a disk to an unassigned slot also can not be done without initializing the array.

 

In conclusion, you have to use the initconfig command to move an existing disk to a new slot.

 

You can also expand to use the "trust my parity" procedure to move the existing disks and then add the new disks after. Just do a Wiki search for it. This will keep the parity valid during the disk re-assigning, meaning you won't have the parity build time where the array is unprotected and vunerable to a failing drive.

 

Peter

 

You can also expand to use the "trust my parity" procedure to move the existing disks and then add the new disks after. Just do a Wiki search for it. This will keep the parity valid during the disk re-assigning, meaning you won't have the parity build time where the array is unprotected and vunerable to a failing drive.

 

Peter

 

The "trust parity" procedure does not work in the past few beta versions.  It was broken in 5.0beta5 when limited hot-plug support was added.

see here: http://lime-technology.com/forum/index.php?topic=13371.msg128980;topicseen#msg128980

The "trust parity" procedure does not work in the past few beta versions.  It was broken in 5.0beta5 when limited hot-plug support was added.

see here: http://lime-technology.com/forum/index.php?topic=13371.msg128980;topicseen#msg128980

 

OP listed he was using 4.7.

 

The "trust parity" procedure does not work in the past few beta versions.  It was broken in 5.0beta5 when limited hot-plug support was added.

see here: http://lime-technology.com/forum/index.php?topic=13371.msg128980;topicseen#msg128980

 

OP listed he was using 4.7.

 

I know, but he was asking about upgrading to 5.0beta

 

Joe L.