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.

Warm Spare disk assignment slot

Featured Replies

If you aren't familiar with the Warm Spare concept, you can read about it here.

 

I'm a big proponent of the warm spare approach.  In both advice on these forums and in servers I've built, I've been telling people to use the cache disk slot to reserve their warm spare (so that you don't accidentally assign it elsewhere), but to not actually use the cache disk functionality if not desired.  I discussed this implementation a bit here.

 

Even using a warm spare as a cache drive doesn't help the situation unless you actually copy huge amounts of data on a regular basis.  If you have a 2 TB warm spare that you use as a cache drive and routinely copy 50 GBs of data to the server every day, only the first 50 GBs of that warm spare would really be exercised regularly.  The other 1950 GBs could be suspect and you wouldn't find out until it was too late (when you are actually using the warm spare to replace a dead drive).

 

A warm spare should always be precleared, so I'll just take that as a given.  This imbues in the user a certain level of trust in the drive.  However, the above approach means the drive is warm, but it isn't ever exercised, or at least it isn't exercised in it's entirety.  This means it could silently go bad.  Parity checks don't invoke the cache disk, so those won't help either.

 

So my thought is this - what if we had a designated 'Warm Spare' slot?  This would be in addition to all the existing disk slots, so a server could look like:

 

Parity + 20 Data disks + Cache + Warm Spare = 23 physical drives

 

The Warm Spare slot would have a few advantages, the chief one being that it would exercise the disk on a regular basis.  This could be achieved either by running some sort of test on it during every parity check, or it could be on a completely separate schedule.  Perhaps preclear the drive once a month?  Is that excessive?

 

I can think of other uses for the Warm Spare slot, but I'll save those for later.  Discuss.

I like the idea of exercising a warm spare on a frequency.

Doing this via cron would suffice with a preclear, yet the downside is, if your drives shift for some reason, you could accidentally preclear the wrong drive.

 

I like the idea of assigning it into the array, now the array will not start if the drive shifts or the system will auto adjust.

This gives you the ability to bank on a /dev/mdx device. for something.

 

What if the warm spare were exercised with parity checks by writing the same parity data to the warm spare.

OK it would just duplicate what parity has, but it certainly would exercise the drive and all the sectors.

 

It also stages reliability for the one day possibility of a HOT SPARE.

 

I was just thinking a moment ago, If I had dual parity capability, I probably would not enable it in favor of a hot spare capability. I had to consider. With dual parity, I still have to replace the failed drive within a certain period of time and all drives are utilized while there is a gap in physical placement.

With hot spare, that cap can be filled automatically within the same period of time it takes to do a parity check.

 

This is just me thinking externally. no flames please, I'm not saying don't do dual parity, just what I would use and why.

I kinda like the idea too. I have a 2TB drive that I precleared just in the event that my parity drive was to die. Now I'm running a bit shy on space and thought maybe I should steal it and put it into use, but if I loose my parity drive then I'd be out and scrambling for a new 2TB drive.

 

If I had it assigned as a warm spare and ready to click into action as a pairty drive then well I'd be more apt to not even bother with it since its setup and ready to be activated. LOL

If I had it assigned as a warm spare and ready to click into action as a pairty drive then...

 

My thought is, it's warm and a spare that is tested on a periodic basis, But it's not for just replacing parity, it can replace any of the drives.

Yeah even better. Unless I'm bonkers the drives are not formatted for either Parity or a data drive until added to the array anyways.

By definition, a drive that is big enough to replace parity is adequate to replace any other drive too.

  • Author

By definition, a drive that is big enough to replace parity is adequate to replace any other drive too.

 

Right, so it would have to be a requirement of the Warm Spare slot that the drive is the same size as the parity drive.  Any smaller and it can't be used to replace a failed parity drive, and any larger and it can't be used to replace a failed data drive.  Unfortunately that requires you purchase two drives every time you upgrade your parity drive, so we would have to be careful to let people know the dangers of buying two drives from the same batch.

By definition, a drive that is big enough to replace parity is adequate to replace any other drive too.

 

Right, so it would have to be a requirement of the Warm Spare slot that the drive is the same size as the parity drive.  Any smaller and it can't be used to replace a failed parity drive, and any larger and it can't be used to replace a failed data drive.  Unfortunately that requires you purchase two drives every time you upgrade your parity drive, so we would have to be careful to let people know the dangers of buying two drives from the same batch.

Not entirely true since the array supports an operation know as parity-swap.

 

If a replacement drive is larger than party you can put it in the parity slot and use the existing parity drive in the data slot.  The array will then first copy the parity data from the old parity drive (now in the data slot) to the new parity drive, and then proceed.  You can always use a drive larger than the parity drive... it is just how you install it and if you need the array to perform the parity swap operation.

By definition, a drive that is big enough to replace parity is adequate to replace any other drive too.

 

Right, so it would have to be a requirement of the Warm Spare slot that the drive is the same size as the parity drive.  Any smaller and it can't be used to replace a failed parity drive, and any larger and it can't be used to replace a failed data drive.  Unfortunately that requires you purchase two drives every time you upgrade your parity drive, so we would have to be careful to let people know the dangers of buying two drives from the same batch.

Not entirely true since the array supports an operation know as parity-swap.

 

If a replacement drive is larger than party you can put it in the parity slot and use the existing parity drive in the data slot.   The array will then first copy the parity data from the old parity drive (now in the data slot) to the new parity drive, and then proceed.  You can always use a drive larger than the parity drive... it is just how you install it and if you need the array to perform the parity swap operation.

 

Is it possible to do a parity swap if the array is full of drives?  Like if a Plus already has 5 drives + parity. 

By definition, a drive that is big enough to replace parity is adequate to replace any other drive too.

 

Right, so it would have to be a requirement of the Warm Spare slot that the drive is the same size as the parity drive.  Any smaller and it can't be used to replace a failed parity drive, and any larger and it can't be used to replace a failed data drive.  Unfortunately that requires you purchase two drives every time you upgrade your parity drive, so we would have to be careful to let people know the dangers of buying two drives from the same batch.

Not entirely true since the array supports an operation know as parity-swap.

 

If a replacement drive is larger than party you can put it in the parity slot and use the existing parity drive in the data slot.   The array will then first copy the parity data from the old parity drive (now in the data slot) to the new parity drive, and then proceed.  You can always use a drive larger than the parity drive... it is just how you install it and if you need the array to perform the parity swap operation.

 

Is it possible to do a parity swap if the array is full of drives?  Like if a Plus already has 5 drives + parity. 

Yes.

 

Assume an array fill of 1TB drives and one of the data disks fails.

 

Take the existing 1TB data drive that failed out of the array. In its place, put the existing 1TB parity drive.

Take the new 1.5 or 2TB drive and install it as the parity drive.

When you start the array the parity will first be copied from the old parity rive to the new, then the re-construction onto the old parity drive now assigned as a data drive, will begin.

 

This takes a LONG time, As it will take at least 3 or 4 hours to copy the one parity disk to the other before the re-construction can begin.  I think during the copy process the array is off-line, but it has been years since I experimented with it when I replaced a drive.

  • Author

Awesome, I didn't know about the Parity Swap function.  So that means a Warm Spare can be the same size or larger than the parity drive, that's good news. 

 

So Parity Swap is already built into unRAID?  If so, then why do we generally advise people to upgrade their parity drive first (doing a full parity rebuild), then install the old parity drive as a data drive?  Doing so takes a long time (full parity rebuild then many hours for clearing the new data drive), whereas it seems that the Parity Swap procedure would be much quicker.

Awesome, I didn't know about the Parity Swap function.  So that means a Warm Spare can be the same size or larger than the parity drive, that's good news. 

 

So Parity Swap is already built into unRAID?  If so, then why do we generally advise people to upgrade their parity drive first (doing a full parity rebuild), then install the old parity drive as a data drive?

Some may be more comfortable doing it as two steps, but that does not work if you have a failure, it only works when upgrading the size of a drive.

 

Also, as I said, the array is probably off-line while the copy from the old parity disk to the new occurs.  Also, you do not have the luxury of replacing parity with a larger disk and rebuilding parity if you have a data drive failure.  (You can't re-calculate parity with a failed drive in the array. ) You must do it in one step with the parity-swap procedure. 

 

Joe L.

I pasted in the section from the official manual .  The parity swap is at the very bottom of the section and is referred to as swap-disable (useless descriptor alert!).

Will the so called parity swap work when no drive failure has occured?  If not then I'm going to recommend it as an important feature enhancement.

 

Disk configuration changes

 

Here are the normal configuration changes you can make:

 

·      You add one or more new disks.

 

·      You replace a single disk with a bigger one.

 

·      You replace a failed disk.

 

·      You shuffle two or more data disks between slots.

 

·      You remove one or more data disks

 

 

 

Add one or more new disks

 

This is the normal case of expanding the capacity of the system by adding one or more new hard drives:

 

1.    Stop the array.

 

2.    Power down the server.

 

3.    Install your new hard drive(s).

 

4.    Power up the unit.

 

5.    Start the array.

 

When you Start the array, the system will first format the new disk(s). When this operation finishes, all the data disks, including the new one(s), will be exported and be available for use.

 

The format operation consists of two phases. First, the the entire contents of the new disk(s) is cleared (written with zeros), and then it's marked active in the array. Next, a file system is created. unRAID Server uses the ReiserFS journalled file system.

 

The clearing phase is necessary to preserve the fault tolerance characteristic of the array. If at any time while the new disk(s) is being cleared, one of the other disks fails, you will still be able to recover the data of the failed disk. Unfortunately, the clearing phase can take several hours depending on the size of the new disks(s).

 

The capacity of any new disk(s) added must be the same size or smaller than your parity disk. If you wish to add a new disk which is larger than your parity disk, then you must instead first replace your parity disk. (You could use your new disk to replace parity, and then use your old parity disk as a new data disk.)

 

 

 

Replace a single disk with a bigger one

 

This is the case where you are replacing a single small disk with a bigger one:

 

1.    Stop the array.

 

2.    Power down the unit.

 

3.    Replace smaller disk with new bigger disk.

 

4.    Power up the unit.

 

5.    Start the array.

 

When you start the array, the system will reconstruct the contents of the original smaller disk onto the new disk. Upon completion, the disk's file system will be expanded to reflect the new size. You can only expand one disk at a time.

 

If you are replacing your existing Parity disk with a bigger one, then when you Start the array, the system will simply start a parity sync onto the new Parity disk.

 

A special case exists when the new bigger disk is also bigger than the existing parity disk. In this case you must use your new disk to first replace parity, and then replace your small disk with your old parity disk:

 

1.    Stop the array.

 

2.    Power down the unit.

 

3.    Replace smaller parity disk with new bigger disk.

 

4.    Power up the unit.

 

5.    Start the array.

 

6.    Wait for Parity-Sync to complete.

 

7.    Stop the array.

 

8.    Power down the unit.

 

Replace smaller data disk with your old parity disk.

 

Power up the unit.

 

Start the array.

 

 

 

Replace a failed disk

 

This is the case where you have replaced a failed disk with a new disk:

 

1.    Stop the array.

 

2.    Power down the unit.

 

3.    Replace the failed hard disk with a new one.

 

4.    Power up the unit.

 

5.    Start the array.

 

When you Start the array after replacing a failed disk, the system will reconstruct the contents of the failed disk onto the new disk; and, if the new disk is bigger, expand the file system.

 

You must replace a failed disk with a disk which is as big or bigger than the original and not bigger than the parity disk. If the replacement disk is larger than your parity disk, then the system permits a special configuration change called swap-disable.

 

For swap-disable, you use your existing parity disk to replace the failed disk, and you install your new big disk as the parity disk:

 

1.    Stop the array.

 

2.    Power down the unit.

 

3.    Replace the parity hard disk with a new bigger one.

 

4.    Replace the failed hard disk with you old parity disk.

 

5.    Power up the unit.

 

6.    Start the array.

 

When you start the array, the system will first copy the parity information to the new parity disk, and then reconstruct the contents of the failed disk.

 

You don't have to have a failure to do the "swap-disable".

If you aren't familiar with the Warm Spare concept, you can read about it here.

 

I'm a big proponent of the warm spare approach.  In both advice on these forums and in servers I've built, I've been telling people to use the cache disk slot to reserve their warm spare (so that you don't accidentally assign it elsewhere), but to not actually use the cache disk functionality if not desired.  I discussed this implementation a bit here.

 

Even using a warm spare as a cache drive doesn't help the situation unless you actually copy huge amounts of data on a regular basis.  If you have a 2 TB warm spare that you use as a cache drive and routinely copy 50 GBs of data to the server every day, only the first 50 GBs of that warm spare would really be exercised regularly.  The other 1950 GBs could be suspect and you wouldn't find out until it was too late (when you are actually using the warm spare to replace a dead drive).

 

A warm spare should always be precleared, so I'll just take that as a given.  This imbues in the user a certain level of trust in the drive.  However, the above approach means the drive is warm, but it isn't ever exercised, or at least it isn't exercised in it's entirety.  This means it could silently go bad.  Parity checks don't invoke the cache disk, so those won't help either.

 

So my thought is this - what if we had a designated 'Warm Spare' slot?  This would be in addition to all the existing disk slots, so a server could look like:

 

Parity + 20 Data disks + Cache + Warm Spare = 23 physical drives

 

The Warm Spare slot would have a few advantages, the chief one being that it would exercise the disk on a regular basis.  This could be achieved either by running some sort of test on it during every parity check, or it could be on a completely separate schedule.  Perhaps preclear the drive once a month?  Is that excessive?

 

I can think of other uses for the Warm Spare slot, but I'll save those for later.  Discuss.

 

I like this idea, but you do not need a dedicated "ware spare" slot in order to implement the concept.  Just add a drive to the server and don't assign it to the array.  Voila - instant warm spare!

 

I actually have 2 such disks in my server right now.  Both are precleared and waiting to be added to the array (or used to replace failed disks).

Yes I had the same setup for a while with a single disk, however I think what is being asked it would be nice if a spare disk(s) could be tested some how now and then to insure they are cycled now and then just in case they are needed to be brough on line.

  • Author

I like this idea, but you do not need a dedicated "ware spare" slot in order to implement the concept.  Just add a drive to the server and don't assign it to the array.  Voila - instant warm spare!

 

I actually have 2 such disks in my server right now.  Both are precleared and waiting to be added to the array (or used to replace failed disks).

 

The problem with this approach is that your warm spare will show up in the drop down menu anytime you add a new drive to your array.  You would have to read all the serial numbers and know which one is your new drive and which one are the warm spare.  While this may be a trivial issue for some of us, I would like to keep things as simple as possible.

 

Also, why do you have two warm spares?  Considering that unRAID can only recover from a single disk failure, I don't see any benefit to having two spares.

 

Also, another feature of the warm spare slot that I just thought of is that it could stay spun down when the server boots to save power.  There's no reason for it to ever be spun up except during it's periodic testing.

The problem with this approach is that your warm spare will show up in the drop down menu anytime you add a new drive to your array.  You would have to read all the serial numbers and know which one is your new drive and which one are the warm spare.  While this may be a trivial issue for some of us, I would like to keep things as simple as possible.

 

I am not sure that the warm spare slot suggestion is going to get high priority from Tom.  My point was, even if he does not implement this specific feature, there is a way for anyone interested to implement the concept with just a little effort.  A user can put the "warm spare" disk in their machine, preclear it, put it to sleep, exercise the disk periodically with a preclear or other script, and be ready for a disk to fail or a need to expand their array.

 

Also, why do you have two warm spares?  Considering that unRAID can only recover from a single disk failure, I don't see any benefit to having two spares.

 

I said I had two precleared disks in my machine that were ready for expansion or to replace failed disks.  I am planning to add them to my array, but was waiting for my new controller card.  They were not intended to be warm spares, but if a disk happened to fail, one of them could be used to rebuild it.

 

In thinking more about the warm spare concept, I am not sure I would ever use it.  If a drive were to actually fail in my server, I would take steps to figure out why, which would inevitably require powering down the server to check cabling.  And with the easily accessible hotswap bays in my computer, I could easily add a "cold spare" to the machine at that time.  Keeping the spare disk outside the machine avoids the dangers of keeping it inside - including risk of getting fried by an electrical storm or similar that fries the connected disks.  The only thing needed to implement a cold spare concept is to have an empty bay in one of the server's backplanes. And for the frugal, the cold spare can live on Newegg's inventory until you need it ;)  You'd just need to wait a couple days to get it, and a couple more to preclear it in another machine.

 

I also like Weebo's idea of installing a large cache disk and planning to repurpose that to do a replacement if needed.

 

Luckily unRAID is very flexible which lets each of us to tweak their environment to meet our own personal needs.

 

Also, another feature of the warm spare slot that I just thought of is that it could stay spun down when the server boots to save power.  There's no reason for it to ever be spun up except during it's periodic testing.

 

User scipts could handle this.

Sounds like a good idea to me. After the preclear would be noce have the warm spare and have some way to check it sometimes, or run some scripts on it to see if it's still in good condition to replace a drive

  • Author

I am not sure that the warm spare slot suggestion is going to get high priority from Tom.  My point was, even if he does not implement this specific feature, there is a way for anyone interested to implement the concept with just a little effort.  A user can put the "warm spare" disk in their machine, preclear it, put it to sleep, exercise the disk periodically with a preclear or other script, and be ready for a disk to fail or a need to expand their array.

 

Very true.  I don't really consider it a high priority either, just a 'would be nice'.  At first I thought this would be very simple for Tom to implement, but now that I've thought about it more it does have some potential complications.

 

I said I had two precleared disks in my machine that were ready for expansion or to replace failed disks.  I am planning to add them to my array, but was waiting for my new controller card.  They were not intended to be warm spares, but if a disk happened to fail, one of them could be used to rebuild it.

 

Makes sense.

 

In thinking more about the warm spare concept, I am not sure I would ever use it.  If a drive were to actually fail in my server, I would take steps to figure out why, which would inevitably require powering down the server to check cabling.  And with the easily accessible hotswap bays in my computer, I could easily add a "cold spare" to the machine at that time.    The only thing needed to implement a cold spare concept is to have an empty bay in one of the server's backplanes.

 

Definitely valid points.  As you mentioned, it comes down to personal preference.  If I had a dead or suspect drive, how I handle it would depend on the amount of free time I have a the moment.  If I had little to no free time, I would just sub in the hot/cold spare, let unRAID rebuild, and set the dead/suspect drive aside for later analysis.  If I had plenty of free time, then I would probably go through all the troubleshooting steps right then, as you would.

 

Keeping the spare disk outside the machine avoids the dangers of keeping it inside - including risk of getting fried by an electrical storm or similar that fries the connected disks.

 

I agree that the cold spare is a bit safer, for the reasons you mentioned, however it is also much more of a pain to run any kind of periodic tests on it.  Again, personal preference.

 

And for the frugal, the cold spare can live on Newegg's inventory until you need it ;)  You'd just need to wait a couple days to get it, and a couple more to preclear it in another machine.

 

That's actually my current plan; as much as I talk about it, I don't have a warm spare.  None of the data on my server is so critical that I can't do without it for a few days or a week.  I would definitely miss my media, but I can always play it from DVDs/CDs, or just read a book or something...

 

 

I also like Weebo's idea of installing a large cache disk and planning to repurpose that to do a replacement if needed.

 

Me too, and I consider this to currently be the best implementation of the warm spare concept.  The problem is that this limits your choice of cache disk.  For example, I'm considering re-purposing an older 30 GB SSD as a cache drive for the benefits of speed, power savings, etc.  Obviously this won't work as a warm spare.  Therefore, I would like to have the option of having a small and fast cache drive in addition to a warm spare (one that is reserved for the purpose, so that it doesn't show up in the drop down menu whenever I add a new disk to my array).

  • 1 month later...

And for the frugal, the cold spare can live on Newegg's inventory until you need it ;)  You'd just need to wait a couple days to get it, and a couple more to preclear it in another machine.

 

Another advantage to this is the benefit of the full length of the warranty.

 

Any kind of a spare, warm tepid cold or otherwise sitting around is eating away at the warranty period.

 

 

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.