January 3, 201610 yr Noob question here. I have six drives on my NAS but they are out of order. They work fine as they are but the slot order goes hda, hdb, hdc, hdd, hdf, hde and I'd like to correct it. Yeah, I know it's trivial but it bugs me. Can I just swap the drives in the slots or is it more complex than that?
January 3, 201610 yr You can swap the drives all you want, but when you're done you'll have to rebuild the parity drive.
January 3, 201610 yr Are these actually IDE drives? Normally IDE drives show up as hda, etc, but SATA drive show up as sda, etc. If these are really SATA drives you should configure your BIOS to use AHCI for these disks. The drive letter is not important and actually out of your control, as unRAID will just assign them in the order they respond when booting. It is even possible they will change from one boot to the next. Only the drive number is meaningful, so forget about it. You could rearrange your drives with New Config and assign different disks to different numbers if you wanted, and this wouldn't affect parity so you could just trust parity and skip the rebuild. But it won't make any difference to the drive letters.
January 3, 201610 yr You can swap the drives all you want, but when you're done you'll have to rebuild the parity drive. Not true => the order in which the drives are assigned has NO impact on parity. You can simply do a New Config; assign the drives as you see fit; and check the "Parity is already valid" box before you Start the array.
January 4, 201610 yr Author Thanks folks. Here's what happened. I just swapped the drives around in the slots and rebooted. They are now in their proper order. Yay! No rebuild or new config necessary. unRAID booted up with the array on line and parity valid. Trurl, I got the designations wrong. They actually are SATA drives (sda, sdb, etc... - flashback from old Linux days.)
January 4, 201610 yr Not true => the order in which the drives are assigned has NO impact on parity. You can simply do a New Config; assign the drives as you see fit; and check the "Parity is already valid" box before you Start the array. I learn something new every day! I rememebr back in the unraid 4.x days being told to take a screenshot of the unraid page (drive order) so that in the event of a new config, the drives were arranged in the same order. When did that requirement go away?
January 4, 201610 yr Not true => the order in which the drives are assigned has NO impact on parity. You can simply do a New Config; assign the drives as you see fit; and check the "Parity is already valid" box before you Start the array. I learn something new every day! I rememebr back in the unraid 4.x days being told to take a screenshot of the unraid page (drive order) so that in the event of a new config, the drives were arranged in the same order. When did that requirement go away? unRAID has kept track of drives by serial number since v5.
January 4, 201610 yr I rememebr back in the unraid 4.x days being told to take a screenshot of the unraid page (drive order) so that in the event of a new config, the drives were arranged in the same order. When did that requirement go away? It happened with v5 when unRAID switched to recognising drives by serial number rather than by where they were plugged in. Having said that I am not sure that the order ever really mattered.
January 4, 201610 yr I rememebr back in the unraid 4.x days being told to take a screenshot of the unraid page (drive order) so that in the event of a new config, the drives were arranged in the same order. When did that requirement go away? It happened with v5 when unRAID switched to recognising drives by serial number rather than by where they were plugged in. Having said that I am not sure that the order ever really mattered. Order definitely mattered with v4 => the serial # tracking started with v5.
January 4, 201610 yr Order definitely mattered with v4 => the serial # tracking started with v5. I know that it mattered for tracking disks. However I doubt that it mattered as far as calculating parity was concerned.
January 4, 201610 yr Correct -- it didn't have any impact on parity ... but I don't believe v4.7 had a "trust parity" option anyway, so if you swapped the order you had to redo the config anyway, which would have forced another parity sync.
January 4, 201610 yr but I don't believe v4.7 had a "trust parity" option It does, but not exposed in the GUI. CLI only. "mdcmd set invalidslot 99"
January 4, 201610 yr but I don't believe v4.7 had a "trust parity" option It does, but not exposed in the GUI. CLI only. "mdcmd set invalidslot 99" Nice to know ... although I doubt I'll ever need it [but I did save this as a note "just in case" I'm ever helping somebody who's still on v4.7]
January 5, 201610 yr but I don't believe v4.7 had a "trust parity" option It does, but not exposed in the GUI. CLI only. "mdcmd set invalidslot 99" Nice to know ... although I doubt I'll ever need it [but I did save this as a note "just in case" I'm ever helping somebody who's still on v4.7] The full procedure for 4.7 is still documented here. http://www.lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily Correctly implementing trust parity in 4.7 is a multi step process, and is rather finicky. The current implementation is MUCH better.
Archived
This topic is now archived and is closed to further replies.