EMPTY and Remove a Drive Without Losing Parity


NAS

Recommended Posts

This can easily be done today with a handful of commands/steps. No, it is not a built in feature, but It is so trivially easy I don't understand the fuss. Stack this against dual parity and other features not achievable without LT development, and this one drops to the bottom of the heap.

Link to comment

This can easily be done today with a handful of commands/steps. No, it is not a built in feature, but It is so trivially easy I don't understand the fuss. Stack this against dual parity and other features not achievable without LT development, and this one drops to the bottom of the heap.

 

If it is simple then it can be supported, otherwise references to unsupported procedures are not a solution.

 

Also referring to other "more important" things is both subjective and pointless.

 

Sorry to be so stark but this is years in and we are still rolling out the same discussions rather than just getting on with it.

 

Edit: wow that reads like a rant  :-X

Link to comment

When we do get dual parity, it seems like it would make it more useful though. The usual way of removing a drive is to invalidate parity. With dual parity, the usual way would be to invalidate both parities?

 

Hmm, with dual parity, removing a disk could still leave a protected array if Tom designed it that way. Might want to put a bug in his ear.

 

The solution that works with single parity is supported by the community, and several users have done it successfully. Funny though, although I developed the original procedure, I have ever so seldom used it. Just not that common I need to remove one drive. And when I do, I typically don't want to delete everything from the drive - I'd rather keep its contents as a backup at least for some period of time. More commonly, I am replacing several smaller drives with fewer larger drives, and the time involved and loss of the data as a backup source lead me to just pull the drives and rebuild parity. But before doing so, I always run a parity check and examine the smart reports minimizing the chance of a drive failure while rebuilding. If a person is replacing / upsizng parity along with removing and/or adding other drives, they CAN maintain parity recoverability by following my "Replace Parity" best practice in my sig.

 

So not only do I not think a single parity removal method is unneeded because a procedure already exists, I think it is unneeded because it just isn't very useful. Now if we had a procedure that would let us remove a newly added disk in an array and use it to rebuild a failed disk in an array, that would be more useful, as this question comes up often. But such a feature is impossible with single parity. With dual parity it might be possible, but your array would be unprotected from a failure while the reconstruction occurred and I'm not sure that would be a popular method. But it could work if Tom built that feature into dual parity.

Link to comment
I think it is unneeded because it just isn't very useful.

I would be happy with just a GUI change that would keep the drives assigned that are not removed and kicked off a parity build.

 

 

I use this quite often so I do NOT agree.  I am currently upgrading from 4TB to 6TB drives (slowly since I can't afford to replace to quickly).  I add 2 6TB drives by replacing 2 4TB and rebuilding one at a time.  Then when I have two in place I move the data off of another 4TB drive into the empty space on the 2 6TB drives and remove it.  I have to do the newconfig and then reassign each drive in the GUI and rebuild parity.  It would be nice if I could remove this step because sooner or later I will screw up and not reassign them correctly and get parity built on a data drive.  My array has 18 drives in it with 2 6TB and 16 4TB.  So I will be doing the swap-copy-rebuild process a number of times before I'm done.  If the GUI would maintain the drives I don't mind having to rebuild parity each time during this process.  I'm not wanting the drive zeroing just maintaining the assignments in the GUI when I remove a drive.  Once that server is done I will probably move on to another server and use 8TB Seagate drives in place of my 3TB Seagates using the same process.

Link to comment

I think it is unneeded because it just isn't very useful.

I would be happy with just a GUI change that would keep the drives assigned that are not removed and kicked off a parity build.

 

 

I use this quite often so I do NOT agree.  I am currently upgrading from 4TB to 6TB drives (slowly since I can't afford to replace to quickly).  I add 2 6TB drives by replacing 2 4TB and rebuilding one at a time.  Then when I have two in place I move the data off of another 4TB drive into the empty space on the 2 6TB drives and remove it.  I have to do the newconfig and then reassign each drive in the GUI and rebuild parity.  It would be nice if I could remove this step because sooner or later I will screw up and not reassign them correctly and get parity built on a data drive.  My array has 18 drives in it with 2 6TB and 16 4TB.  So I will be doing the swap-copy-rebuild process a number of times before I'm done.  If the GUI would maintain the drives I don't mind having to rebuild parity each time during this process.  I'm not wanting the drive zeroing just maintaining the assignments in the GUI when I remove a drive.  Once that server is done I will probably move on to another server and use 8TB Seagate drives in place of my 3TB Seagates using the same process.

 

I do agree with you - but do not equate the fact that unRAID loses its drive assignments on a new config operation with the ability to remove a drive from the array without loosing parity. I see now they are related, but I still see them as separate topics.

 

One of the changes that happened in 5.0, I believe, was the new config action unassigned all the drives from the array and slots. Previously, doing the new config equivalent just deleted the array, but all of the slots previously assigned to the array became "blue balls", as though they had been assigned one by one through the GUI. The user was then able to remove any drives from the array by selecting that option from the drive dropdown before starting the array. Starting the array locked the drives to the array. But for situations like you describe, where you were only trying to remove a single drive, it was quite handy. I would like this feature to come back as well.

 

I am not sure, but it is possible that if you copied the disk.cfg file to a different name before doing the new config, then copied it back afterwards, and refreshed the GUI, that it would return all of those disks as blue balls. That is because disk.cfg records the slot assignments, but super.dat records the array configuration. When drives are blue balls (or whatever they are in today's GUI), they are stored in disk.cfg but not in super.dat. When the array is started, the disk.cfg configuration is stored in the super.dat, and then the icons become green. I think all that Tom would have to do to enable the feature you are requesting is not alter the disk.cfg on a new config. I don't think trying what I describe would cause any harm, even it it didn't work as I expect it would.

Link to comment

I think it is unneeded because it just isn't very useful.

I would be happy with just a GUI change that would keep the drives assigned that are not removed and kicked off a parity build.

 

 

I use this quite often so I do NOT agree.  I am currently upgrading from 4TB to 6TB drives (slowly since I can't afford to replace to quickly).  I add 2 6TB drives by replacing 2 4TB and rebuilding one at a time.  Then when I have two in place I move the data off of another 4TB drive into the empty space on the 2 6TB drives and remove it.  I have to do the newconfig and then reassign each drive in the GUI and rebuild parity.  It would be nice if I could remove this step because sooner or later I will screw up and not reassign them correctly and get parity built on a data drive.  My array has 18 drives in it with 2 6TB and 16 4TB.  So I will be doing the swap-copy-rebuild process a number of times before I'm done.  If the GUI would maintain the drives I don't mind having to rebuild parity each time during this process.  I'm not wanting the drive zeroing just maintaining the assignments in the GUI when I remove a drive.  Once that server is done I will probably move on to another server and use 8TB Seagate drives in place of my 3TB Seagates using the same process.

 

I do agree with you - but do not equate the fact that unRAID loses its drive assignments on a new config operation with the ability to remove a drive from the array without loosing parity. I see now they are related, but I still see them as separate topics.

 

One of the changes that happened in 5.0, I believe, was the new config action unassigned all the drives from the array and slots. Previously, doing the new config equivalent just deleted the array, but all of the slots previously assigned to the array became "blue balls", as though they had been assigned one by one through the GUI. The user was then able to remove any drives from the array by selecting that option from the drive dropdown before starting the array. Starting the array locked the drives to the array. But for situations like you describe, where you were only trying to remove a single drive, it was quite handy. I would like this feature to come back as well.

 

I am not sure, but it is possible that if you copied the disk.cfg file to a different name before doing the new config, then copied it back afterwards, and refreshed the GUI, that it would return all of those disks as blue balls. That is because disk.cfg records the slot assignments, but super.dat records the array configuration. When drives are blue balls (or whatever they are in today's GUI), they are stored in disk.cfg but not in super.dat. When the array is started, the disk.cfg configuration is stored in the super.dat, and then the icons become green. I think all that Tom would have to do to enable the feature you are requesting is not alter the disk.cfg on a new config. I don't think trying what I describe would cause any harm, even it it didn't work as I expect it would.

If that works it would be fine for me and definitely sounds like it could be done in the GUI like that.  Will try it maybe as early as this weekend.
Link to comment

It's a topic that occasionally comes up and generates a bit of buzz ... then kinda fades out  :)

 

As bjp999 noted, there is a fairly simple way to remove a drive without losing parity (not sure I'd call it "trivial", as he does, because many users don't want to mess with Linux command line "stuff") ... basically you simply write all zeroes to the drive (this will update parity as it's being done) ... and then you can do a New Config with the "Trust Parity" option (check the "Parity is already valid" box) without including the drive you just zeroed.

 

But I also agree with Brian (bjp999) that it's simple enough to just do a New Config and let parity rebuild ... this eliminates the need to write zeroes (thus preserving the data on the drive you're removing) ... and is very low risk as long as you've done a parity check BEFORE doing that and have checked for any SMART warnings about pending drive failures (easy to do with MyMain).

 

Link to comment

I am not sure, but it is possible that if you copied the disk.cfg file to a different name before doing the new config, then copied it back afterwards, and refreshed the GUI, that it would return all of those disks as blue balls. That is because disk.cfg records the slot assignments, but super.dat records the array configuration. When drives are blue balls (or whatever they are in today's GUI), they are stored in disk.cfg but not in super.dat. When the array is started, the disk.cfg configuration is stored in the super.dat, and then the icons become green. I think all that Tom would have to do to enable the feature you are requesting is not alter the disk.cfg on a new config. I don't think trying what I describe would cause any harm, even it it didn't work as I expect it would.

 

After "running this up the flagpole", I have been told that my information is dated. Although what I describe is exactly the way unRAID worked back in the pre-5.0 days (when I was writing myMain and doing a lot of research into the inner workings of unRAID), that the role of disk.cfg has been scaled back, and the role of super.dat has been expanded, meaning that now even the pre-array slot configurations are stored in super.dat.

 

A possible solution, would be to copy the super.dat file to another name just prior to starting an array for the very first time with a new configuration. Then, perhaps months later when it is time to reconfigure the array again, after doing a new config, you could try replacing the super.dat file with the copy of the super.dat file you saved previously. And then again, just before starting the reconfigured array, you could save a copy of the super.dat file for use next time.

 

This requires foresight and planning, and could fit into the "more trouble than it is worth" category, but might work for people like BobPhoenex that do this on a regular basis.

 

BTW, this is getting some airplay in a moderator discussion. The other mods tend to agree with Bob and I that an option to maintain the slot configuration would be useful when doing a new config. We'll see with LT thinks.

Link to comment

This is idea is like the matrix. I honestly believe we have had 6+ completely separate design threads about it over the last decade.

 

What I can say is behind the scenes it seems to be getting some traction.

 

Could not be happier its a feature that will benefit me greatly.

Link to comment
  • 2 weeks later...

I don't know if this is really the correct thread to ask this question so the moderator might chip in and remove it if needed.

 

I followed this guide:

- move all data out of the drive that will be removed

- stop the array

- start the array in "Maintenance mode" (or manually unmount the disk to be removed like on original steps)

- zero the drive that will be removed, on telnet using something like:

  dd if=/dev/zero bs=2048k of=/dev/mdX

  wait it to finish...

- stop the array

- reset the array at Utils -> New Config

- reassign all hard disks except the one to be removed

- make sure to enable the option "Parity is already valid" and start the array

 

Instead of using dd if=/dev/zero bs=2048k of=/dev/mdX I used dd if=/dev/zero bs=2048k of=/dev/sdg which is the correct drive. The issue now is that the parity speed is horrible slow (13MB/sec and I have actually 1263313 Sync errors corrected. The drive was empty but showed 1,3GB but I don't see that any data is missing).

 

What should I do? Any advise appreciated. Thanks a lot.

Link to comment

I don't know if this is really the correct thread to ask this question so the moderator might chip in and remove it if needed.

 

I followed this guide:

- move all data out of the drive that will be removed

- stop the array

- start the array in "Maintenance mode" (or manually unmount the disk to be removed like on original steps)

- zero the drive that will be removed, on telnet using something like:

  dd if=/dev/zero bs=2048k of=/dev/mdX

  wait it to finish...

- stop the array

- reset the array at Utils -> New Config

- reassign all hard disks except the one to be removed

- make sure to enable the option "Parity is already valid" and start the array

 

Instead of using dd if=/dev/zero bs=2048k of=/dev/mdX I used dd if=/dev/zero bs=2048k of=/dev/sdg which is the correct drive. The issue now is that the parity speed is horrible slow (13MB/sec and I have actually 1263313 Sync errors corrected. The drive was empty but showed 1,3GB but I don't see that any data is missing).

 

What should I do? Any advise appreciated. Thanks a lot.

The whole point of the procedure is to maintain parity while removing a drive, but instead of writing to the md device, which would have updated parity as it was zeroing the drive, you wrote to the sd device, so parity was not included in the zeroing.

 

You might as well do New Config again, and this time, don't check the box that says parity is valid, since it isn't and it will have to be rebuilt.

Link to comment
  • 1 month later...

OK, here is a slightly different "remove a disk" scenario.  I want to remove a disk and rearrange the disks that remain in different slots.  Here's the scenario.

 

Current hardware/array config:

 

-1 parity drive

-5 data drives

-1 cache drive

-Lian-Li PC Q25 case with 5 hot-swap slots and room for more drives on a bottom tray.

I currently have 4 data drives and the parity drive in the hot swap slots (data disk4 is "empty"; it has been formatted XFS but show 0% usage. A check on console of /mnt/disk4 confirms it has no shares/folders/files on it)

-1 data disk and SSD cache drive on bottom tray

-MB has 4 SATA connectors

-4-port SATA card in PCIE slot of mini-ITX MB

 

What I want to do:

-install new MB with 6 onboard SATA3 connectors

-eliminate empty data disk4

-connect 4 data disks and parity to different slots in hotswap bay and different slots than currently configured in unRAID

-connect SSD cache drive to remaining MB SATA port and leave in bottom tray

-eliminate completely the SATA card in PCIE slot

-I will increase capacity with larger drives instead of more disks in this system.

 

I just completed a parity check and smart reports on all drives in current config.  All look good.

 

Can I still just stop array, do a new config without the empty disk 4 with disks in new slots and run another parity check on completion to accomplish all the above?

Link to comment

Yes, parity sync.  But, is this the correct procedure?

 

1 - Shut down server

2 - Make hardware changes

3 - Place disks in new slots (eliminating empty disk)

4 - Boot server (comes up with array stopped)

5 - Do new config

6 - Run Parity Sync

Yes. Note that New Config requires you to reassign your drives. Be sure you know which is parity and cache.
Link to comment

If you really want to remove a drive and leave parity undisturbed, this will work:

1. Start array in Maintenance mode.  This ensures no file systems are mounted.

2. Identify which disk you're removing, let's say it's disk3.  Take a screen shot.

3. From the command line type:

dd bs=1M if=/dev/zero of=/dev/md3   <-- 'md3' here corresponds to 'disk3'

4. Go to bed because this will take a long time.

5. When the command completes, Stop array, go to Utils page, click 'New Config' and execute that Utility.

6. Go back to Main, assign Parity, and all devices except the one you just cleared.

7. Click checkbox "Parity is already valid.", and click Start

 

That all makes sense, but I'm wondering if the system being in Maintenance mode is a suggestion or a requirement.  With two drives to clear it would be nice to keep it running, and a cache drive will keep it in basically read-only mode if the mover is temporarily disabled...

Link to comment

If you really want to remove a drive and leave parity undisturbed, this will work:

1. Start array in Maintenance mode.  This ensures no file systems are mounted.

2. Identify which disk you're removing, let's say it's disk3.  Take a screen shot.

3. From the command line type:

dd bs=1M if=/dev/zero of=/dev/md3   <-- 'md3' here corresponds to 'disk3'

4. Go to bed because this will take a long time.

5. When the command completes, Stop array, go to Utils page, click 'New Config' and execute that Utility.

6. Go back to Main, assign Parity, and all devices except the one you just cleared.

7. Click checkbox "Parity is already valid.", and click Start

 

That all makes sense, but I'm wondering if the system being in Maintenance mode is a suggestion or a requirement.  With two drives to clear it would be nice to keep it running, and a cache drive will keep it in basically read-only mode if the mover is temporarily disabled...

I'd be a little nervous trying to run normal while clearing.  Like the old days of command line use of reiserfsck, you would need to stop all sharing and unmount the drive first.  For you that would mean make sure that disk sharing is turned off for the drive (not just not use it but turn it off), make sure that user shares are turned off (not just not used) for the drive (exclude it perhaps), make sure NOTHING is set to write to it, make sure that CacheDirs is disabled or reconfigured to skip the drive, then after starting the array unmount the drive (with umount).  Could be other things too, but that's all I can think of at the moment.  Array will be in an odd state during all of this, so once clearing is complete, stop the array, and don't start it until after New Config without the drive.

 

I can't recommend doing this.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.