Make unRAID Trust the Parity Drive, Avoid Rebuilding Parity Unnecessarily

From unRAID

Jump to: navigation, search

The 'Trust My Array' Procedure


It should NEVER be used if you have a failed disk or are in the process of replacing a failed disk.
It should NEVER be used if you are replacing a drive with one of a larger size.
It should NEVER be used if you are adding or removing disks in the array.

It is ONLY to be used if exactly the same the drives last used to perform a full parity calculation are present, and working, AND only those exact same drives are currently assigned to the array. If any are missing, or any disks have been added, or deleted, or have failed since the last full parity calculation, this procedure will falsely lead you to think parity protection is in effect when it is not.
It should probably NOT be used if you were writing files to the drive that was disabled.

Note: THIS PROCEDURE DOES NOT WORK THE SAME IN ANY RECENT 5.X SERIES OF UNRAID. If you refresh the web-interface, the commands you entered will be undone. You will then be overwriting parity. Consider yourself warned.

There are various situations where unRAID may not think that the parity drive is currently valid, and want to totally rebuild it. Since that involves reading from every single sector of every data drive, and rewriting the entire parity drive, it is natural to want to avoid that if you know that your current parity drive is completely valid, perfectly good.

Some of the situations where this may apply:

  • Disk drive re-arrangements, such as changing the disk numbers or physically moving the drives to different ports, may confuse unRAID, and result in unRAID assuming the parity drive is no longer valid for the current configuration. (If desired, see "What is the safe way to rearrange disk numbers, assignments, slots, etc?")
  • Disk controller or cable faults that result in loss of communications to one or more drives, causing the drive(s) to be marked Disabled, displayed with a <red> ball, even though they are fine and were not written to
  • A disk drive that fails to spin back up, causing the drive to be marked Disabled, even though it is fine and was not written to
  • Drive randomly not recognized by BIOS on boot, perhaps because of flaky motherboard, causing drive to be dropped from array
  • Parity drive was removed, then re-assigned, but no important changes were made to it or any of the data drives (small changes will result in a few parity errors on the ensuing parity check)
  • Upgrading from unRAID v4.3.1 or earlier, to v4.3.2 or later, AND you have Western Digital or Hitachi drives with very long model names (see this)
  • There may be other situations too, but if you KNOW that you have the same set of drives that are associated with (and used to calculate) the current parity drive, then this procedure should restore the array and re-validate the parity drive. It does not matter if the drives are numbered differently, or moved to different cables, ports, and controllers. But the parity drive MUST be correctly assigned(!), and the exact same set of drives must be assigned, in which ever slots you want them

A situation where this procedure may NOT apply:

  • You wish the keep the data that was in the process of being written when the "write" to the disk failed.

If a disk is off-line, it is because a "write" to it failed. If the drive went off-line when you were saving the only copy of important files/music/pictures/movies, etc then the failed drive does not contain any of the data that was written to it. Any files written to the failed drive were recorded in parity, but not the physical data drive. It is entirely possible to load the entire failed disk with files, but only upate parity and not the physical data disk, because it is disabled.

If you use this procedure, it will force the disabled back online, and when the resulting parity check proceeds, it will be updated to reflect the data on the physical disk. In other words, using this procedure will bring the disk back without the new files written to it when it went off-line or any written to it since that time. You will effectively rolled back the clock, as if they were never written to the array.

A subsequent parity check will contain many errors, as it is brought in sync with the physical disk contents. Remember, the disk was taken off-line because a write to it failed.

If you want to preserve the data that was written to the failed drive, you must un-assign the drive, start the array, stop the array, re-assign the drive, and let unRAID re-construct the contents as created by parity and all the other data drives. They can reconstruct a full copy of what was written to the array based on parity and the other data drives. You will not have parity protection during this period of time, but you will have the latest data written.

So, you can choose. Get back the data you were writing to the failed disk by NOT using this procedure, or get back immediate parity protection (but knowing it must have errors, because a write to the physical drive failed, so it may not really be usable in all recovery situations until after a full parity check is performed.)


Here is a procedure provided by Tom of Lime Technology. Do this only if you know your configuration is completely valid, no disabled or missing disks, all disks correctly assigned, and you are sure that your parity drive is good. The data drives do NOT have to be assigned to the same slots as they were previously.

  • Boot unRAID, but DO NOT START the array. Stop the array if it has started.
  • Make sure that all of your disks are correctly assigned, not disabled or missing. Note: they do not have to be assigned to the same slots they were originally assigned to, except for the Parity drive(!), but it MUST be the same set of drives.
  • Open a console, either at the unRAID server or in a Telnet or PuTTY window. Make sure you are in the home directory, which is /root. If you are unsure, type cd and press the Enter key, and you will be there.
  • If you are running any version of unRAID that is PRIOR to v4.5.4, then at the unRAID Web Management page, click the Restore button, after first checking the "I'm sure I want to do this" box.
  • If you are running unRAID version v4.5.4 or later, then log in as root at your system console or via telnet and type the following command: 
initconfig
  • If necessary, refresh your unRAID Web Management Main page in your browser. For UnRaid 4.7 ensure you DO NOT refresh the unRAID Web Management Main page in your browser (for reasons that are explained here).
  • On the unRAID Web Management Main page, this should result in all disk status symbols/balls turning <Blue>. The server status should indicate "Stopped. Initial Configuration".
  • Now at the unRAID console or Telnet or PuTTY prompt, type this command: (Please see this thread for v5 updated syntax. Upon verification, info here will be updated too.) 
mdcmd set invalidslot 99
  • The output of this command should be this: 
cmdOper=set
cmdResult=ok

In the case of UnRaid 4.7, there will be no such output (again, for reasons that are explained here).

  • Now click the Start button. All the disk status indicators should turn <Green>; the system state should be Started; and there should be a parity check in progress. You can let the parity check complete, or you can cancel it. In most cases, you should let it finish. If you were correct and parity was valid, the parity check will not find any errors. If you were wrong, then the parity check will find and correct the errors, and report them. By the time the parity check reports on the parity errors, they will have already been corrected.


For more information, see the original post and thread.

For version 4.7 and 5.0 series, see this post. See also this post.

Retrieved from "http://lime-technology.com/wiki/index.php/Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily"
Personal tools