Guys,

 

In my Microserver N40L I currently have 1x 3TB WD Green as parity and another 3TB WD Green and 2x 1.5TB Samsungs as data drives.

 

Getting a bit low on space so have ordered a 4TB Seagate. Obviously to use the new drive I have to add it in place of the current parity drive and then to gain extra data space I have to add the old parity drive as a data drive.

 

First of all I'm going to run a few preclear cycles (3 at a minimum) on the new drive, but once that's done my thinking on the sequence to follow is:

 

1. Stop array and shutdown server

2. Remove the current parity drive and replace it with the new drive.

3. Start the server back up, assign the new drive as parity and let unraid do a parity rebuild.

4. Once the rebuild is done, do a parity check to confirm no errors.

5. Assuming that works out ok, stop the array and shutdown the server.

6. Install the old parity drive back into the machine.

7. Start the server up again and do a preclear on the old parity drive (only 1 cycle needed I guess as it's been precleared before and running as parity for a year with no issues)

8. When the preclear is finished, stop the array and assign the old parity drive as a new data drive.

 

Does that sound about right?

 

With step 7 - preclearing the old parity drive - is that needed? I know that preclearing isn't required before adding a drive to the array, but I'd obviously like to avoid the array downtime of unraid clearing a drive when it's added. The current parity drive was precleared before being installed in the first place and has only been used as a parity drive since.

 

Thanks

 

Peter

 

Edit:- Just to add I'm running v5 rc11 at this point. Haven't gotten round to upgrading as yet. May well do that first, to rc16c or whatever is the latest, before embarking on the above adventure.

Two changes ...

 

(1)  Step 0 ==> BEFORE you do anything else, run a parity check and confirm everything's okay.  Resolve any issues before continuing (hopefully it's a clean check)

 

(2)  r.e. Step 7 ... while a full pre-clear cycle certainly doesn't hurt, it's certainly true the drive's been well exercised for the past year, and was well tested before then, so you can, if you choose, skip all the extra testing.  You can run preclear with the -n option and it will ONLY do the pre-clear ... skipping both the pre-read and post-read cycles.  This cuts the preclear time by about 75% 

e.g. if the drive is sdc, the command would be:

 

preclear_disk.sh -n /dev/sdc

 

Agree with your edit (posted while I wrote the above) => you may as well upgrade to RC16c before doing the above steps.    There MAY be a newer release posted very soon -- so check the current release tomorrow before you do the upgrade.

 

Thanks for the reply.

 

Yes I'll do a parity check before actually making any change to the configuration. Most likely after the new drive has finished preclearing.

 

Thanks for the tip about the preclear -n option, I wasn't aware of that.

 

I saw that there are hints of a new release coming soon. I've been keeping a watchful eye on the releases recently. After 16c got some good reports I thought that final would be along shortly after. So I was hanging on for that rather than go to 16c then soon after go to final.

 

As the machine will be powered down and restarted at least twice during the process of installing/moving drives I'll take the opportunity to upgrade.

Ok I've done steps 0 (the initial parity check suggested by garycase) to 3 (rebuilding parity on the new drive).

 

The machine is currently running step 4 (doing a parity check following the rebuild).

 

Before I started the rebuild in step 3 I disabled any plugins that would write to or interact with the array drives (sickbeard, couchpotato, plex) and avoided accessing the server at all, as I didn't want anything happening that might cause unwanted effects during the rebuild.

 

However, I've just found out that sickbeard hadn't shutdown as intended (my bad - I trusted the stop button on the plugin page and didn't follow up by checking that it was actually disabled). During the night, while the parity rebuild was running, sickbeard grabbed and processed some tv shows.

 

Will that happening during the rebuild have caused any issues?

 

As I say, I am currently running a parity check (a correcting parity check apparently due to a bug that causes the first check after a restart to be a correcting one).

Reading or writing to the array during a parity build would just make the parity build slower.