If I wanted to reassign the disk's (which have data on them) that I have in Position 11 and 12 to Positions 14 and 15, would I just change 11, 12 to "Unassigned" and reassign those drives to 14,15

 

 

Then I assume I would have to do a "restore"? (since it's the only option I appear to have)

 

If I wanted to reassign the disk's (which have data on them) that I have in Position 11 and 12 to Positions 14 and 15, would I just change 11, 12 to "Unassigned" and reassign those drives to 14,15

 

 

Then I assume I would have to do a "restore"? (since it's the only option I appear to have)

 

Yes, you must use the "restore" button in this situation.  The unRaid driver is not smart enough to deal with moving drives from existing assigned slots to un-assigned slots.  (It is smart enough to deal with moving swapping them around the currently assigned slots.  From what I see in the code, one more "for" loop would do it, but for now, it is not there, so "restore" is your only option.

 

Pressing the button will immediately rename your super.dat file to  super.old,  effectively removing it.  (it is a very poorly named button, as it does not restore anything) When the unRaid array sees it gone, it will create a new system.dat based on the currently existing assigned drives.  Parity status is stored in the super.dat file, and since the file is created new unRaid will assume it has never done a prior parity check, and will not have  any way of knowing parity is good, so it will think it has to rebuild it and proceed to do so.

 

There is a workaround to it thinking parity is bad, and doing a full parity check, but only proceed to do it if you are absolutely certain all your drives are ok and parity is valid.  It is described in this post: http://lime-technology.com/forum/index.php?topic=2191.msg16518#msg16518

 

After pressing "restore" and before starting the array, log in via telnet and type the command as indicated in the post I mentioned.

unRaid will still do a parity check, but will assume parity is good to start with.  I'd let the parity check run to completion.

 

Joe L.

Yes, you must use the "restore" button in this situation.  The unRaid driver is not smart enough to deal with moving drives from existing assigned slots to un-assigned slots.  (It is smart enough to deal with moving swapping them around the currently assigned slots.  From what I see in the code, one more "for" loop would do it, but for now, it is not there, so "restore" is your only option.

 

This is by design.  What we want to ensure is that a user knows which hard drive is assigned to each "slot".  This is because in the case where a disk gets disabled, you want to ensure that the user pulls the right disk.  Hence any time there is a slot configuration change, ie, changing disk assignments, the server requires explicit user action.

 

Pressing the button will immediately rename your super.dat file to  super.old,  effectively removing it.  (it is a very poorly named button, as it does not restore anything)

It restores the configuration to it's default state, i.e., all drives appear "new", as if you just built the system.

 

The term originated as a result of building servers.  In the manufacturing process we test servers by first plugging in a fresh Flash device and populating all the drive slots with a known set of hard drives.  Upon system boot we then verify that all the drives appear as "new" disks on the Main page, and also verify that each disk appears to be assigned to the correct hard drive (by s/n).  This verifies that all the internal cables are connected properly.  We then Start the array and run the server through a series of tests.  Finally, we restore the configuration to that of a "fresh" system and prepare the server for shipment.  Hence the name Restore for the button.

 

When the unRaid array sees it gone, it will create a new system.dat based on the currently existing assigned drives.  Parity status is stored in the super.dat file, and since the file is created new unRaid will assume it has never done a prior parity check, and will not have  any way of knowing parity is good, so it will think it has to rebuild it and proceed to do so.

 

There is a workaround to it thinking parity is bad, and doing a full parity check, but only proceed to do it if you are absolutely certain all your drives are ok and parity is valid.  It is described in this post: http://lime-technology.com/forum/index.php?topic=2191.msg16518#msg16518

 

After pressing "restore" and before starting the array, log in via telnet and type the command as indicated in the post I mentioned.

unRaid will still do a parity check, but will assume parity is good to start with.  I'd let the parity check run to completion.

 

Joe L.

 

What the Devices assignment is actually doing is not assigning specific hard drives to disk identifiers.  What it's doing is assigning specific ports to disk identifiers.  We are just using the model/serial no. as an aide to the user to properly identify the ports.

all drives appear "new", as if you just built the system.

 

Even that comment above, at least to me could be taken, from someone who isn't as intimate to the product as many on this forum, as "I'm going to lose my data"... When my drives were "new", they had no data on them.  Making them "new" again to me says the data is going to be gone... My data really is my #1 concern...everything else is secondary

 

Not to get into "another" tangent of the semantics of the wording on the buttons, "Restore" in my world (Corporate Desktop Support in a MS Windows world for 15+ years), means I'm going to pull DATA off of some type back-device and put it back to where it started because it was lost damaged or otherwise gone off of the original location.

 

So I think I agree with Joe that the wording of "Restore", for someone that isn't in the "server" world makes things challenging (and I think I've asked two or three times before I hit restore for various situations, and most probably will ask again)

 

 

so I think I agree with Joe that the wording of "Restore", for someone that isn't in the "server" world makes things challenging (and I think I've asked two or three times before I hit restore for various situations, and most probably will ask again)

 

I'm with everyone else on this one. restore usually means grabbing something from a backup to use as current.

In the context of unRAID functionality, it's more like Initialize where it backs up the super block and re-creates it.

 

This is by design.  What we want to ensure is that a user knows which hard drive is assigned to each "slot".  This is because in the case where a disk gets disabled, you want to ensure that the user pulls the right disk.  Hence any time there is a slot configuration change, ie, changing disk assignments, the server requires explicit user action.

 

I've often wondered if it would be worthwhile to use the serial number of the drive as the assignment selector for the slot.

I.E. use the /dev/disk/by-id

 

I just find that every now and then a drive may not initialize correctly on bootup.

At other times I'll plug in something to the eSata port, and all the drive id's shift by one.

This in turn leads to a different device id, thereby causing me to have to adjust.