Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Question about removing a disk from array.

Featured Replies

If I want to remove a disk from the array do I have to set a new config? Or are there other ways?

 

If I set a new config can I then group 4 TB, 3 TB and 2 TB disks together, only for esthetics?

 

  • Community Expert

If I want to remove a disk from the array do I have to set a new config? Or are there other ways?

At the moment a new config is the only easy way. Note that this will invalidate parity and you will have to rebuild parity so make sure that your disks are all good before you do this.  There is a feature request on the roadmap for an official ability to remove disks while maintaining parity but it is not there yet.  Also, make sure you know which drive is the parity drive as you do not want to assign a data drive as a parity drive by accident thus losing its contents.

 

If I set a new config can I then group 4 TB, 3 TB and 2 TB disks together, only for esthetics?

The order in which disks are assigned is completely up to you.

There is a relatively simple method to remove a disk from the array that involves filling the disk you want to remove with binary zeros. It can then be removed doing a new config and selecting the trust parity checkbox.

 

The assignment of disks to slots can be changed in an existing array. With array stopped, exchange two disk assignments. It will tell you that the disk assignments will be exchanged when you start the array. I believe you have to do it two at a time, but can easily get the disk order to where you want it in a few steps. (I haven't done this in a while but I expect it still works).

  • Author

I added a new precleared 4 tb disk to the array, set it to XFS then moved data from a ReiserFS disk to it. When that disk was empty I set it to XFS, moved data from the next disk etc, etc, etc. That way I converted all disks to XFS ran parity checks a few times and am now left with an empty disk that I want to move to another server.

 

I think that I stop the array, set a new config and set the disk order to my liking at the same time.

 

Should I run a correcting parity check first? Or a non-correcting parity check?

  • Community Expert

II think that I stop the array, set a new config and set the disk order to my liking at the same time.

 

Should I run a correcting parity check first? Or a non-correcting parity check?

If you have just done a new config then you have no parity at that point.    You should therefore start by doing a run to create parity, and when that completes do a non-correcting check to make sure that it was done correctly.

  • Author

II think that I stop the array, set a new config and set the disk order to my liking at the same time.

 

Should I run a correcting parity check first? Or a non-correcting parity check?

If you have just done a new config then you have no parity at that point.    You should therefore start by doing a run to create parity, and when that completes do a non-correcting check to make sure that it was done correctly.

 

The question is should I run the parity check before setting the new config and should that one be a correcting or non-correcting one. But I see no reason for a parity check before setting a new config, or is there?

II think that I stop the array, set a new config and set the disk order to my liking at the same time.

 

Should I run a correcting parity check first? Or a non-correcting parity check?

If you have just done a new config then you have no parity at that point.    You should therefore start by doing a run to create parity, and when that completes do a non-correcting check to make sure that it was done correctly.

 

The question is should I run the parity check before setting the new config and should that one be a correcting or non-correcting one. But I see no reason for a parity check before setting a new config, or is there?

Not really since the moment you click on new config, you have no parity.  If anything run smart reports on your drives to make sure none look to be failing soon or have some other issue beforehand.
  • Community Expert

The question is should I run the parity check before setting the new config and should that one be a correcting or non-correcting one. But I see no reason for a parity check before setting a new config, or is there?

The only reason for running a parity check before removing a drive would be as a confidence check that all your drives are OK (since the new config would discard the results).

 

Note that there is an unofficial command line based way to be able to remove a disk and keep parity valid based on writing zeroes to the drive to be removed.  However for most people I suspect the process is a bit more than they want to undertake and possibly a bit error-prone. 

Agree that the process needed to remove a drive without losing isn't worth the hassle => basically you have to write zeroes to the entire drive, then do a parity check to confirm all is well (which you should always do anyway before modifying your config in any way);  and then you can do a New Config and check the "Trust Parity" box, since you know the drive you removed had no impact on the calculation.

 

I'd simply do this to remove a drive ...

 

(1)  Do a parity check (correcting) to ensure your drives are all okay.  If there are any sync errors corrected, then do it again to ensure there are NO errors in parity before you start.

 

(2)  Do the New Config and set the configuration you want.  You can assign the drives in any order you want -- but be CERTAIN that the parity and (if you have one) cache drives are set correctly.

 

(3)  Start the array and wait for the initial parity sync to complete.

 

(4)  Do a parity check (correcting) to confirm the parity sync went okay.

 

Done  :)

 

The only time I ever recommend doing a non-correcting parity check is immediately after a drive rebuild ... as a confirmation that the rebuild went okay.    In that case, if the rebuild did NOT work well, you don't want to modify your parity drive, as you'll want to repeat the rebuild.

 

The only time I ever recommend doing a non-correcting parity check is immediately after a drive rebuild ... as a confirmation that the rebuild went okay.    In that case, if the rebuild did NOT work well, you don't want to modify your parity drive, as you'll want to repeat the rebuild.

 

A non-correcting check should be performed any time there is a question whether parity should be accurate. For example,

- after doing a new config trusting parity

- when a drive may have been updated outside of parity protection (e.g., using its "sdX" instead of "mdX" designator, updated outside the array or updated on a difference machine)

- after certain types of system recovery techniques have been employed leaving parity in an unknown state

- any time you suspect a hardware problem (bad memory, bad controller, loose cable, etc.)

 

Not understanding doing it after a drive rebuild. The disk would be rebuilt such that parity would be valid. A non-correcting check after this seems unnecessary unless a hardware problem is suspected - in which case you should never have done the rebuild.

Not understanding doing it after a drive rebuild. The disk would be rebuilt such that parity would be valid. A non-correcting check after this seems unnecessary unless a hardware problem is suspected - in which case you should never have done the rebuild.

 

A drive rebuild does NOT do a verify after the writes.    A non-correcting check simply verifies that everything's okay.  If not, you can do another rebuild and repeat the process.    This is no different than doing a check after the initial parity sync to confirm that the parity disk was written okay -- except in that case there's no reason for it to be non-correcting, since if the parity disk was NOT written properly you'd want to correct it.

 

 

A non-correcting check should be performed ...

- after doing a new config trusting parity

 

??  Okay, you've just "trusted parity".    If you're right, that's good -- a parity check (correcting or non-correcting) will confirm that.  If you're wrong, you clearly WANT parity to be correct ... so a correcting check will fix it.    Why would you not WANT parity to be correct?    If you run a non-correcting check, and it shows parity was not in fact correct, what would your next step be?  I suspect you'd do an initial parity sync ... the results of which would be identical to simply running a correcting check in the first place.

 

 

A non-correcting check should be performed ...

- when a drive may have been updated outside of parity protection (e.g., using its "sdX" instead of "mdX" designator, updated outside the array or updated on a difference machine)

 

If you've done this, I'd think the first thing you want to do is get parity up-to-date !!  (i.e. run a correcting check)

 

 

A non-correcting check should be performed ...

- after certain types of system recovery techniques have been employed leaving parity in an unknown state

 

Ditto my previous comment ["If you've done this, I'd think the first thing you want to do is get parity up-to-date !!"]

 

 

A non-correcting check should be performed ...

- any time you suspect a hardware problem (bad memory, bad controller, loose cable, etc.)

 

Agree.  Although I'd also note that in most cases it doesn't take a parity check (correcting or non-correcting) to isolate hardware problems  :)

Not understanding doing it after a drive rebuild. The disk would be rebuilt such that parity would be valid. A non-correcting check after this seems unnecessary unless a hardware problem is suspected - in which case you should never have done the rebuild.

 

A drive rebuild does NOT do a verify after the writes.    A non-correcting check simply verifies that everything's okay.  If not, you can do another rebuild and repeat the process.    This is no different than doing a check after the initial parity sync to confirm that the parity disk was written okay -- except in that case there's no reason for it to be non-correcting, since if the parity disk was NOT written properly you'd want to correct it.

 

I suppose this would be a good quality check. If it failed it would mean you have a hardware problem.

 

A non-correcting check should be performed ...

- after doing a new config trusting parity

 

??  Okay, you've just "trusted parity".    If you're right, that's good -- a parity check (correcting or non-correcting) will confirm that.  If you're wrong, you clearly WANT parity to be correct ... so a correcting check will fix it.    Why would you not WANT parity to be correct?    If you run a non-correcting check, and it shows parity was not in fact correct, what would your next step be?  I suspect you'd do an initial parity sync ... the results of which would be identical to simply running a correcting check in the first place.

 

I have seen too many times that a person has not assembled an array correctly and does the trust parity while in the middle of a delicate recovery. Doing a correcting check may be disastrous.

 

A non-correcting check should be performed ...

- when a drive may have been updated outside of parity protection (e.g., using its "sdX" instead of "mdX" designator, updated outside the array or updated on a difference machine)

 

If you've done this, I'd think the first thing you want to do is get parity up-to-date !!  (i.e. run a correcting check)

 

It depends on why the user updated it outside the array. If he totally FUBARed the disk and is trying to rebuild it from parity and the other disks, the last thing you want to do is a correcting check.

 

A non-correcting check should be performed ...

- after certain types of system recovery techniques have been employed leaving parity in an unknown state

 

Ditto my previous comment ["If you've done this, I'd think the first thing you want to do is get parity up-to-date !!"]

 

Ditto my previous comment. There are no absolutes here.

 

A non-correcting check should be performed ...

- any time you suspect a hardware problem (bad memory, bad controller, loose cable, etc.)

 

Agree.  Although I'd also note that in most cases it doesn't take a parity check (correcting or non-correcting) to isolate hardware problems  :)

 

Agree, maybe I should switch this around to say never do a correcting check when you suspect you may have a hardware problem.

 

I'd caution people to ask questions in the forum about whether to do a correcting, non-correcting check, or neither if they are confused. Gary's advice is generally sound, but there are times and situations where, due to missteps or confounding factors, doing a correcting check can destroy all chances at recovery. Remember that a non-correcting check can do no harm - so if in doubt, do that. Note that normally a correcting and non-correcting check will both confirm that there are no parity mismatches and are interchangeable. A parity error should be an exceptionally odd scenario!

I certainly agree that "... a non-correcting check can do no harm."  :)

 

I don't agree that a parity error discovered after a rebuild means  you have a hardware problem ... except of course for the disk you just rebuilt.    But if there was in fact an unreported write error on the disk you just rebuilt, you want to be able to do it again on a different disk -- whence the non-correcting check.

 

I've said many times you can't protect everyone from obviously wrong actions [i won't use the "s" word  :) ]    Checking the "Trust Parity" box is NOT something that should ever be done unless you're CERTAIN that it's correct ... or have some esoteric reason you want to do that and use a parity check instead of an initial parity sync to get your parity correct [i can't think of any reason to ever do that].

Checking the box when you're not CERTAIN it's true is a mistake that you can't reasonably expect UnRAID to compensate for.

 

Similarly, if a user has " ... totally FUBARed the disk and is trying to rebuild it from parity and the other disks, the last thing you want to do is a correcting check."    Actually, the last thing he wants to do in that situation is ANY parity check.    At that point, a parity check accomplishes nothing.    A non-correcting check will just show that parity is royally hosed -- which he already knows.  A correcting check would clearly update parity, but if the user already knows parity is hosed and has some reason he doesn't want it fixed, then clearly he doesn't want to do that either.    If the user doesn't KNOW those things, he has no business doing what he's trying to do !!  If the goal is to simply rebuild the disk, then do the rebuild.  PERIOD.    If parity wasn't good to start with, the rebuild won't be good either ... but it may recover at least some of the previous data.

 

It certainly doesn't hurt to do a non-correcting check anytime you feel like it.    But since it in fact does NOTHING except report whether or not you have any sync errors, it's not much use.    I do parity checks monthly, and have 3 servers, so I've probably done on the order of 200 parity checks on my systems -- NONE have ever been non-correcting except after disk rebuilds.

 

 

 

  • Author

Questions regarding speed:

 

1. Is the initial parity build much slower than a parity check?

 

2. What speed can I expect for the parity build on my Mainserver (see my sig.)

 

3. Will using a single 4 TB or 6 TB disk on the M1015 for parity be much faster.

 

4. Will using a single M1015 plus RES240 expander slowdown parity build and check?

 

5. Am I right that a parity build is a one time affair after a new server build or when upgrading or replacing a parity disk?

 

 

1. Is the initial parity build much slower than a parity check?

 

It will be a bit slower, since the parity disk has to be written for every block.    But it shouldn't take dramatically longer, since the next set of reads for the other disks can overlap the current parity write.

 

 

2. What speed can I expect for the parity build on my Mainserver (see my sig.)

 

Impossible to say.  You have what I assume is a very fast parity "disk" (the RAID-0 array); but you also have a mix of 2, 3, and 4 TB drives, so you'll have several slowdown points (as the build gets near the inner cylinders of each size respectively.  I presume you know how long your parity checks have been taking -- it will likely be just a bit longer than that.

 

 

3. Will using a single 4 TB or 6 TB disk on the M1015 for parity be much faster.

 

It's doubtful, since the data disks are likely slower than your current RAID-0 parity "disk".    Remember that a parity check (or build; or disk rebuild) can never go faster than the slowest disk currently involved in the operation.

 

 

4. Will using a single M1015 plus RES240 expander slowdown parity build and check?

 

Port expanders definitely tend to slow things down; since any operation that requires simultaneous access from ALL of your disks will be subject to the impact of the expander on the SATA port.    To determine just what impact, do the math:  take the speed of your SATA port (300MB/s or 600MB/s) and divide it by the number of drives on an expander on that port.  That will be the maximum possible speed/drive during a parity check/build operation.  If it's less than the sustained data rate of the drives, then it's a bottleneck.

 

 

5. Am I right that a parity build is a one time affair after a new server build or when upgrading or replacing a parity disk?

 

You'll need to do a parity sync (parity build) after a new server build or after a "New Config" on that build.    You don't actually do a new parity sync when you replace the parity disk -- it will be treated as a drive rebuild => although computationally it's the same thing.

 

 

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.