I am going to remove a drive on my unraid. The drive is now empty. I found the guide on:

https://lime-technology.com/wiki/index.php/Shrink_array

 

But for my version 6.1.9 it does tell me to do a removal and then rebuild parity. As I understand, my array isnt protected during this time. For version 6.2.0 (beta?) it is described a method how to keep parity in sync during removal. I found some post guides for doing this on older unraid version. eg:

https://lime-technology.com/forum/index.php?topic=6728.0 (see reply #6)

 

Isn't it possible for me to remove a drive and preserve my parity in sync?

 

Kind Regards Jens

 

The script Rob made should work the same on v6.1, follow the wiki instructions.

So you are basicly saying that I should follow the instructions for the 6.2 version?

 

/Jens

Yes the procedure is the same, I believe the script will work but if it doesn't use the alternate steps 7 and 8.

 

The only thing you can't do is step 4, enable turbo write on the GUI, you can still do it on the console:

 

mdcmd set md_write_method 1

 

This has to be done after starting the array because it will revert back every time it's restarted.

 

I got an error message stating:

Unmounting Disk 2 ...

Clearing  Disk 2 ...

dd: invalid status flag: ‘progress’

Try 'dd --help' for more information.

 

A message saying "error writing ... no space left" is expected, NOT an error.

 

I guess that the version of DD in the 6.1.9 doesnt support the "status==progress" flag.

 

/Jens

Yes, forgot about that, remove that from the command.

Rather thoughtless of me!  I can't remember ever even thinking about 6.1.9 when I did it!  I should add a note about that, basically saying what Johnnie said.

 

This procedure is not expected to be used much, and 6.1.9's life is almost over, but would a 6.1 (and 6.0) version be useful?  The main issue is that if users want progress display, I'll need to loop the dd's in something like 1GB slices.  Or I can easily do it without progress.  I should have checked the unRAID version!

...would a 6.1 (and 6.0) version be useful?...

I consider 6.0 more EOL than v5 since it can't be downloaded anymore and may not work with some addons.

... but would a 6.1 (and 6.0) version be useful?

 

Don't see any reason to do anything except note the changes that need to be made if using it with those earlier versions.    This isn't really a common thing to do ... and most folks probably just do a New Config without the drive(s) they want to remove anyway.  There's very little risk in that approach, as long as you do a parity check BEFORE the change to ensure everything's okay.

 

...would a 6.1 (and 6.0) version be useful?...

I consider 6.0 more EOL than v5 since it can't be downloaded anymore and may not work with some addons.

... but would a 6.1 (and 6.0) version be useful?

 

Don't see any reason to do anything except note the changes that need to be made if using it with those earlier versions.    This isn't really a common thing to do ... and most folks probably just do a New Config without the drive(s) they want to remove anyway.  There's very little risk in that approach, as long as you do a parity check BEFORE the change to ensure everything's okay.

 

I think you're both right.  But since it was easy (except for fighting bash syntax!), I've added a version check and made the progress display conditional.  Should now work all the way back to v5.  And I added a short paragraph to the Shrink Array wiki (for older versions) to make it *possible* (but not easy) to adapt the 6.2 parity protecting procedure.  Depending on how old your version is, there's quite a bit of it that has to be modified.

 

There's one other advantage to the parity protecting method, it can be much faster, if the drive to clear is much smaller than the parity drive, and turbo write is turned on.  It only runs for the size of the small drive then, not the parity drive size.  I took advantage of that in my testing, removing a 250GB data drive with a 5TB parity drive.

... There's one other advantage to the parity protecting method, it can be much faster, if the drive to clear is much smaller than the parity drive, and turbo write is turned on.  It only runs for the size of the small drive then, not the parity drive size.  I took advantage of that in my testing, removing a 250GB data drive with a 5TB parity drive.

 

True => and in fact it's very likely that will generally be the case, since the most common reason for wanting to "shrink" an array is it's just been upgraded with a new, larger parity drive, and a few equally large data drives, so the older (often much smaller) data drives are no longer needed and the user wants to simply remove them from the system.