I've just finished putting together a 3x1.5TB system and copied all my data to it ( using up just over 1TB in space ). I have a spare 1.5TB that I was planning to add to the array after I got comfortable with using it.

 

What I want to do is remove one of the drives ( the one that's half full - all shares are on high water allocation ) while I'm actually watching a movie that's on the disk I'm going to remove to see if it can serve the missing files from parity. I then plan to stop the array and power down, insert my spare 1.5TB and start it back up. What should happen is the array would auto-rebuild without user intervention?

 

So at the end of the day I should have 2x1.5TB with the exact same data on it - the original and the spare. Now because I've actually pre-cleaned the original drive ( I haven't pre-cleaned the spare yet) , I'd like to re-use that in the array. So I want to remove the spare and replace it with the original drive, at this point, would the array complain that it's a different drive and want to do a parity rebuild? If it would complain, is it safe to use the "trust my array" procedure? The drives are identical.

 

And when the day comes to add the spare as the 4th drive, I assume I'd have to format it first before adding it to the array otherwise unraid would think it belongs there due to having the correct filesystem and everything, and probably just ask to rebuild the parity drive for all the dupe'd data.

 

Thanks in advance

Easy.

 

Stop the array.

Go to the devices page, un-assign a drive

Go back to the main page, Start the array by pressing "Start"

Test to see you can still get to the contents of the un-assigned drive, and you can still write to it, even though it is being simulated by the unRAID software.    Un-assigning the drive is exactly the same to unRAID as a drive failing.

 

To perform the re-construction of the drive, stop the array once more, re-assign the disk.

Go back to the main page and press "Start" once more (you may need to check the box under it to enable it)  

unRAID will re-construct the original contents onto the "replacement."  Un-assigning, Starting/stopping the array without it, and re-assigning will make it think it is a new drive.

 

While the re-construction is occurring you'll still be able to read and write to the drive.

 

Whatever you do, do NOT press the button labeled as "restore" with an un-assigned or failed drive, as that immediately invalidates parity and sets a new disk configuration.  The button labeled as "restore" has nothing to do with re-constructing data to a failed drive's replacement.  Think of it as a "Set Initial Disk Configuration" button.

 

Joe L.

I've just finished putting together a 3x1.5TB system and copied all my data to it ( using up just over 1TB in space ). I have a spare 1.5TB that I was planning to add to the array after I got comfortable with using it.

 

What I want to do is remove one of the drives ( the one that's half full - all shares are on high water allocation ) while I'm actually watching a movie that's on the disk I'm going to remove to see if it can serve the missing files from parity. I then plan to stop the array and power down, insert my spare 1.5TB and start it back up. What should happen is the array would auto-rebuild without user intervention?

No, you'll need to press the "Start" button.

So at the end of the day I should have 2x1.5TB with the exact same data on it - the original and the spare. Now because I've actually pre-cleaned the original drive ( I haven't pre-cleaned the spare yet) , I'd like to re-use that in the array. So I want to remove the spare and replace it with the original drive, at this point, would the array complain that it's a different drive and want to do a parity rebuild?

It would not start on its own, it would complain.

If it would complain, is it safe to use the "trust my array" procedure? The drives are identical.

Probably safe, but I'd let the trust parity check run to completion anyway.

And when the day comes to add the spare as the 4th drive, I assume I'd have to format it first before adding it to the array otherwise unraid would think it belongs there due to having the correct filesystem and everything, and probably just ask to rebuild the parity drive for all the dupe'd data.

 

Thanks in advance

It would be easiest if it is not already formatted, and much quicker, since as you said it would immediately invalidate parity.  Do not "format it", but use the preclear_disk.sh script to partition it and delete any existing formatting.  It makes adding an additional disk to the array much easier.

 

Joe L.

You always take some small risk by un-plugging a disk while powered up.  Some hardware will deal with it well, some will not.

Let us know how you do.  If your hardware supports hot-plugging, odds are it will go as planned. unRAID itself does not support hot-plugging, but you should be able to simulate a disk failure that way.

 

unRAID will not automatically restore a failed disk, even if you plug it back in and it works perfectly.  You MUST replace a disk that fails with either a different disk, or make unRAID think it is a different disk by un-assigning it, starting the array with it un-assigned, and then re-assigning it. (It will forget the original model/serial number of the failed disk when you start the array with it un-assigned)

 

Joe L.

Could you do something like force the unmounting of the drive with the array running Joe? Would that not simulate a catastropic disk failure?

 

Peter

Could you do something like force the unmounting of the drive with the array running Joe? Would that not simulate a catastropic disk failure?

 

Peter

I don't think you can un-mount a drive if it is in use.

 

But, there are two commands that I see in the "md" driver source code that might be able to do as you desire.... force a read or write error to be simulated on a disk.

 

They are:

set rderror X

and

set wrerror X

 

where X = a drive number. (0=parity)

 

I've never played with these.  But from reading the md driver source code, setting the flag will simulate the error from the disk.

 

To use these to simulate a write error to disk2, you would type

/root/mdcmd set wrerror 2

or to simulate a read error from disk 12 you would type

/root/mdcmd set rderror 12

 

If you set the "write error flag" you would hit this logic:

if (simulate_wr_error[disk_number]) {
                simulate_wr_error[disk_number] = 0;
                uptodate = 0;
        }

        if (!uptodate) {
                printk("md: disk%d write error\n", disk_number);
                mddev->rdev[disk_number].errors++;

                /* this will stop recovery if it's running */
                md_interrupt_thread(mddev->recovery_thread);

                /* Mark the failing disk "not enabled" and "not valid".
                 */

 

If you set the simulate read error flag, you would run this code:

/* called when a read completes, with device_lock held */
int md_done_rd(mddev_t *mddev, int disk_number, int uptodate)
{
        if (simulate_rd_error[disk_number]) {
                simulate_rd_error[disk_number] = 0;
                uptodate = 0;
        }

        if (!uptodate) {
                printk("md: disk%d read error\n", disk_number);
                mddev->rdev[disk_number].errors++;
        }

 

You are on your own in using these.  Odds are very high they are how lime-technology tests its logic.

 

Joe L.

OK, I thought the -f command would force the unmount, file system in use or not, but I guess not.

 

Those other comands look like they'd do it.

 

Peter

 

OK, I thought the -f command would force the unmount, file system in use or not, but I guess not.

 

Those other comands look like they'd do it.

 

Peter

 

To "force" an unmount you use the "-l" (lazy) option. It will force an unmount whether there are open files on that mount or not.

OK, I thought the -f command would force the unmount, file system in use or not, but I guess not.

 

Those other comands look like they'd do it.

 

Peter

 

To "force" an unmount you use the "-l" (lazy) option. It will force an unmount whether there are open files on that mount or not.

The issue is that the raw /dev/sdX1 partition on the disk is not mounted, the "md" device is.   un-mounting the md device does not disable the md device from accessing the partition on the disk.  In fact, it is exactly that way we run reiserfsck on the "md" devices.  The resulting fixes are applied to both the data disk and the parity disk is kept in sync.

 

Therefore, un-mounting will not have the effect you are looking for.  

 

To simulate a disk failure with the array running, you either must use the "set xxerror" to simulate an error, or disconnect the drive physically.

With the array stopped, un-assigning a disk will simulate a missing (dead) disk.

I have an Asus P7H55-M-Pro board that supports AHCI so hotswapping should be supported. I gave it a try while watching a HD movie. In the middle I physically removed the drive and my windows playback buffer held for about 3 -5 seconds and then the video stopped, but I could still hear the audio going on. Pressing pause and then unpause resumed my video perfectly. I can even seek through the video like there was nothing wrong with the array.

 

Setup is the board I mentioned above + 2x2GB DDR3 + Core i3 530. Haven't measured idle power usage but so far I'm quite impressed with the robustness of the system. I've stopped the array, unassigned the drive I pulled out, powered down and put it back in and reassigned in. Now it's going to take just under 8 hours to restore a 3TB array

As someone who's not yet an unRAID user, it's very reassuring to hear stories like this.  Thanks for your efforts.