I recently replaced my parity drive with a larger drive. Everything is good to go. I now want to replace the smallest drive in my array with my old parity drive. Do I need to preclear the old parity drive or somehow wipe it clean, or will unRaid be OK if I do a standard power down -> unplug old drive -> plug in new (old parity) drive?

a preclear is never a bad idea no matter when

 

a rebuild will force it to restore all the possible blocks on the drive, thus i dont think a time difference will be noted.

 

pre clearing just adds that peace of mind

Pre-clearing serves two functions:

 

(1)  It gives a new drive a thorough test by reading/writing all the sectors and exercising the seek mechanism a lot.    This is not needed with your old parity drive, as it's had a LOT of testing just by virtue of being used as the parity drive for (I presume) many months (or even years).  ... although it never hurts to do just a bit more testing 

 

(2)  It writes all zeroes to the drive and adds a special "pre-clear" signature to the drive; so when you add it to the array it will be added immediately instead of requiring a complete clearing of the drive -- which will make the array unusable during that operation (which takes MANY hours).    This is a very good reason to do a pre-clear.

 

Bottom line:  Do at least one cycle of pre-clear just so your array's availability won't be impacted when you add the drive.  [The array is fully available during a pre-clear, since that's a separate Linux task.]

 

I now want to replace the smallest drive in my array with my old parity drive.

Bottom line:  Do at least one cycle of pre-clear just so your array's availability won't be impacted when you add the drive.

Replacing an existing slot in unraid NEVER requires clearing the drive, as all bits will be rewritten from parity and the other drives. Preclear does nothing in that case but test the drive and in Smitty2k1's case, since it's a recently used parity drive we are talking about, a smart report should be all that is needed to verify that the drive is ok.

I now want to replace the smallest drive in my array with my old parity drive.

Bottom line:  Do at least one cycle of pre-clear just so your array's availability won't be impacted when you add the drive.

Replacing an existing slot in unraid NEVER requires clearing the drive, as all bits will be rewritten from parity and the other drives. Preclear does nothing in that case but test the drive and in Smitty2k1's case, since it's a recently used parity drive we are talking about, a smart report should be all that is needed to verify that the drive is ok.

 

Certainly agree ... I was clearly too tired when I wrote that ==> missed (or forgot) that he wasn't adding the old parity drive as an additional drive, but was doing a rebuild of a smaller drive 

Thanks for all the feedback everyone. I just pulled the old drive and plugged in the new drive (old parity).

 

For whatever reason, I couldn't connect to my GUI through "tower" and instead had to look up the IP address. After it connected for the first time everything seems fine.

 

Everything re-built fine over night, and it is now doing a parity check while I'm at work.

I still think one of the important jobs on the unraid todo list is to not recommend or use this method.

 

You array should not be in failed mode for an extended period just to upgrade a disk.

 

Toms idea of dual write eventual drop one disk should ideally come sooner rather than never

I still think one of the important jobs on the unraid todo list is to not recommend or use this method.

 

You array should not be in failed mode for an extended period just to upgrade a disk.

 

Toms idea of dual write eventual drop one disk should ideally come sooner rather than never

 

As long as you do NOT write ANYTHING to the array during the rebuild, the array isn't really running "at risk" when you're simply upgrading to a larger disk.  If you should get a failure on another disk during this process, you could (a) shut down; (b) replace the original (smaller) disk; and then Start the array with the "Trust Parity" option.

 

However ... I agree that a simple "Copy disk to larger replacement" option that would copy an entire disk; then zero the remainder of the new disk; and then prompt you to shutdown and physically replace the disk would be a preferable option.    It would also be nice if this would work via USB, so those who already have all their SATA ports and/or disk space occupied could do it via a USB bridge device.

 

Yeah thats the point... thats a lot of IFs and a tad convoluted. It also relys on no one in your home using unRAID for maybe as long as a day.

 

Toms proposed method sounds far slicker and deals with the problem of cycling old for new disks.... a problem most people will have

I agree (as I noted above).  The safest implementation of a "copy disk to newer one" would also require locking writes to that disk during the process ... but otherwise wouldn't have to impact array operations.

 

But a "safe" rebuild does not require that "... no one in your home ..." uses UnRAID ... only that you don't WRITE to it.

 

I cant locate the thread but the idea revolved around writing to both disks until the old disk was mirrored and then making the old disk RO and swapping to the using solely new one.

 

The idea was this would all be hidden from the end user and is IMHO still the way to go.

I cant locate the thread but the idea revolved around writing to both disks until the old disk was mirrored and then making the old disk RO and swapping to the using solely new one.

 

The idea was this would all be hidden from the end user and is IMHO still the way to go.

 

Ahh ... basically make a temporary RAID-1 array out of the two disks;  then zero the extra space on the 2nd one => and then do the replacement.    Not a bad idea ... although it has one notable "flaw" for a lot of folks:  you need both space for the extra drive and an available SATA port.  Letting it run from a USB bridge device would eliminate that issue, but would also slow things down to USB read/write speeds (perhaps not a bad trade-off for the added safety).    Of course the BEST way for your data to be "safe" is to have good backups