I would like to see how Unraid would react to a failed disk, in practice, not just in theory. BUT I want to make sure I do it in non-disruptive way. UnRaid is a VM in an ESXi 5.0 host, with an IBM BR10i passthru.

 

The easiest way I can think of is, shut down the VM, shutdown the physical host, remove one of the drives, and power everything back up and see what happens. Is that too risky?

 

I have backups, offsite - which I have already tested ... but I need to know what the UnRaid behavior would be like, so that I am properly prepared for a failed disk.

 

Any thoughts?

You can do it without disconnecting anything if you like.    The "md" driver has a way to fake/force a disk to have a "write" error the next time it is accessed.

 

The command is

/root/mdcmd  wrerror  N

where N= 0 (for parity), 1 for disk1, 2 for disk2, etc.

 

The next write to that disk should then fail and should force the disk as disabled (same as if a real "write" to it failed for some reason),

and then you can go about dealing with it for practice.

 

Another way, stop the array, un-assign a drive, and then re-start the array... again it will be simulated as "missing"

Then you can stop the array once more, re-assign it, and see it re-constructed from parity and the other disks.

 

A third way... just unplug a data or power cable (if your disk controller hardware is hot-plug compatible)

 

Joe L.

You can do it without disconnecting anything if you like.    The "md" driver has a way to fake/force a disk to have a "write" error the next time it is accessed.

 

The command is

/root/mdcmd  wrerror  N

where N= 0 (for parity), 1 for disk1, 2 for disk2, etc.

 

The next write to that disk should then fail and should force the disk as disabled (same as if a real "write" to it failed for some reason),

 

I've always just unplugged the disk, but it's nice to know you can do it this way.

 

Question for Joe:  If you use this command, is that going to force a rebuild?  Or will it just update the disk with the missed write?    If you unplug a disk, you can then access the array with no problem (no need to write to the disk), and when you plug it back in all is well (with no rebuild).    Just curious if this works the same way.    And do you need to issue any additional Linux command to make everything "well", or is the "wrerror" automatically reset after the first "fake" error?

 

You can do it without disconnecting anything if you like.    The "md" driver has a way to fake/force a disk to have a "write" error the next time it is accessed.

 

The command is

/root/mdcmd  wrerror  N

where N= 0 (for parity), 1 for disk1, 2 for disk2, etc.

 

The next write to that disk should then fail and should force the disk as disabled (same as if a real "write" to it failed for some reason),

and then you can go about dealing with it for practice.

 

Another way, stop the array, un-assign a drive, and then re-start the array... again it will be simulated as "missing"

Then you can stop the array once more, re-assign it, and see it re-constructed from parity and the other disks.

 

A third way... just unplug a data or power cable (if your disk controller hardware is hot-plug compatible)

 

Joe L.

 

thanks - i like that second option..i think my disk controller and my drive cage (Norco ss-400) are both hot-plug compatible; however, i'd read something about drives getting fried during a hotplug, so my simulation could go very real very quickly.

 

moving around VMs at some point crashplan went bonkers, and is pretty much resyncing my data ... once that is 100% complete, I am going to try this.