As mentioned in another thread, I've been trying to get parity-swap (swap-disable?) mode working and having some problems.  But it seems to me this would be easier/more robust (from a user perspective) if this was done in two steps:

 

1> When a disk is missing from the array, give an option to convert the parity disk into the missing data disk (with appropriate are-you-sure style checkbox).

 

2> Once this is done, now just add new disk as the parity, and start the normal parity sync.

 

 

My understanding is the current code does these steps sequentially anyway, so separating would more or less be just a gui change...?  Though it sounds like not a lot of people actually do parity-swaps -- I'm guessing because their drives are all the same sizes, or they do the 2 swaps whenever they add a big drive (first swap parity, then swap old parity for smallest drive)

 

 

What has happened is that the price on larger drives has dropped to where it makes no sense to get a smaller drive to replace a failed one.  I think that is why we are seeing a lot of people attempting a "parity swap" now.

 

For example, my parity drive, and several of my data drives are 500 Gig.  If any drive were to fail I would purchase a 750 Gig drive as it is only about $150 on sale.  I would have to go through the same pain you are.  At the time I set up my array I purchased two 500 gig drives, at a good price, but still way more than they cost today...(I think nearly $300 each)

 

What you are describing is possible, but if interrupted in any way you might never recover the failed data.  That is because the contents of the parity drive are needed to calculate the missing data.  As you wrote it, it would erase the correct parity data.

 

Joe L.

With all of these hard drive failures I keep reading about on the forum, (cuz we mostly only read about problems), It seems wise to have some sort of hot spare mechanism in place so the rebuild of a failed drive is automatic.

 

 

...

What you are describing is possible, but if interrupted in any way you might never recover the failed data.  That is because the contents of the parity drive are needed to calculate the missing data.  As you wrote it, it would erase the correct parity data.

 

 

 

For an upgrade, I think this is a tolerable disk since all you're doing is thrashing the parity drive, and the old data drive still exists (just probably not in the array).  For replacing a failed drive, isn't this just as dangerous as the current parity-swap method?

 

Or does the current method build the new parity drive as a restored drive n, copy it to the old parity drive, resize, then rebuild parity?  I guess logically that would be the safest technique, although never going through the process I can't really tell.  That would be great if its the technique used....

 

The idea of moving the parity disk to the slot of a previously failed data disk, and then reconstructing the data disk "in place" is a good one - probably could do this fairly easily.

 

The way 'swap-disable' works (or is supposed to work, see below), is that you move the parity disk to the failed disk's slot, and install a new, presumably larger disk in the parity slot.  The first step of 'swap-disable' is to copy the old parity info to the new parity disk.  Once this completes, then the configuration is changed and a normal reconstruct takes place.  This is the "safest" because if the initial copy to the new parity disk fails, then we have not clobbered the parity data.

 

Alas, there's a bug in the code which prevents the 'swap-disable' config state being recognized.  This is fixed in upcoming 4.3 release.

The idea of moving the parity disk to the slot of a previously failed data disk is NOT a good one.

 

Why?

 

If the failure is not sourced on the hard disk but rather the cable or some controller stupidity (both rare but possible), then you immediately destroy the parity data too and loose your failed disk data.

 

Now if this could be prevented somehow (or the parity disk could be frozen in a semi-data-semi-parity state and able to resume back to any of the two states, in case something like that happens) then ok, else the risk is big.

 

When a disk fails, the first thing a user should do, is to REPLACE it. No other mixed scenario. After you replace the disk, do as you like.

 

This is my take.

 

 

The idea of moving the parity disk to the slot of a previously failed data disk is NOT a good one.

 

Why?

 

If the failure is not sourced on the hard disk but rather the cable or some controller stupidity (both rare but possible), then you immediately destroy the parity data too and loose your failed disk data.

I believe Tom is using 'moving' in the virtual sense, not physically moving or changing anything, but adjusting the drive assignments on the Devices page.

 

Omv's idea is creative, and might be a useful option temporarily, perhaps if you are short of replacement drives and money.  What omv is trying to do is move the virtual contents of the failed drive to a physical disk, in place of the parity drive.  The array is vulnerable either way, but you are safer having all of your data on physical disks with no parity, than having a drive whose contents are only virtual.  If anything else goes wrong, then your parity drive may be toast, AND your virtual drive with it.

 

But I have to agree with Joe and NLS about its riskiness.  This new process HAS to be completely successful, or you may lose it AND the contents of the failed drive.  The swap-disable procedure is safer because parity is never risked across the process.  The parity drive is preserved until it has been replicated onto a new parity drive.

 

Probably the first step most of us would take would be to analyze the failed drive.  Once we know if the data is all lost (drive not spinning or otherwise un-responsive), all safe (bad cable or controller or minor fix with reiserfsck), or only a minor loss (a fixable bad sector), then we can judge the best course of action, and the amount of risk we face.

 

Hot spares have been requested before, and I believe are on the Requested Features list, but I think I like the idea of a 'warm' spare better.  Hot spares imply that if a drive is failed, it is immediately replaced by the hot spare, with no user intervention.  It is important in 'high availability' situations.  It is associated with traditional RAID systems where all of the drives are essentially of equal size.  In unRAID, high availability has not been the critical goal, and drives can be many different sizes and ages.  I think most of us would want to be notified of the failure immediately (web management page, console message, email, YAC message, etc), and then analyze the situation, and make our own decision on the best course of action.  It would be nice to have a 'warm spare', a drive already installed and tested and ready for any emergency action, that we could quickly put online even from a remote location.  That could greatly decrease downtime and the vulnerability of the array.  I don't think I would want unRAID to automatically bring it online in some situations though.  For a somewhat extreme example, say I install and test and hold in reserve a new terabyte drive.  I may also have in my array an old 60GB drive (just because I can), and because I know that even if it's on its last legs, my parity protection is covering it.  So the 60GB drive fails.  Now if I am running out of space and just about to add the terabyte drive any way, then having unRAID automatically reconstruct the 60GB onto it is fine.  But in most cases, I would probably want to move the data from the failed 60GB drive to other locations, and keep my terabyte drive in reserve, ready to replace my big drives.

 

Hot spares have been requested before, and I believe are on the Requested Features list, but I think I like the idea of a 'warm' spare better.  Hot spares imply that if a drive is failed, it is immediately replaced by the hot spare, with no user intervention.  It is important in 'high availability' situations.  It is associated with traditional RAID systems where all of the drives are essentially of equal size.  In unRAID, high availability has not been the critical goal, and drives can be many different sizes and ages.  I think most of us would want to be notified of the failure immediately (web management page, console message, email, YAC message, etc), and then analyze the situation, and make our own decision on the best course of action.  It would be nice to have a 'warm spare', a drive already installed and tested and ready for any emergency action, that we could quickly put online even from a remote location.  That could greatly decrease downtime and the vulnerability of the array.  I don't think I would want unRAID to automatically bring it online in some situations though. 

We currently have the ability to install a "warm spare" drive.  Simply install it, but leave it unassigned.

 

If you wish you can use commands from the telnet prompt to partition it and create a file system on it... or...

assign it to your array, have unRaid clear and format it, and then un-assign it.

 

Subsequently, if a data disk fails, it is easy to mount the "warm" un-assigned disk to an empty directory and then copy the contents of the failed drive to the new "warm spare" (the contents being re-constructed from parity and the remaining assigned data disks)

 

Once you have a copy of the failed drive's data you can then stop the array, assign the "warm" drive in place of the failed drive, and re-start the array having it re-compute parity.

 

All of this can be done remotely.... as long as you have the "warm" drive in place and e-mail or YAC notifications in place that alert you of a drive's failure so you can act in a reasonable time (before a second drive fails).

 

Joe L.

I like the idea of a warm spare.

And like what is mentioned, you can always move files manually through telnet.

 

What I would love to see is a simple disk migration strategy from the web front end that allows moving whole drives and expanding to another Disk.. This includes parity which is something you cannot do from the command line (at least I do not know how).

 

So at the very least if during a failure situation, you can migrate parity to a newer larger drive from a front end/command line.

Then that would satisfy the requirements to free up an older drive for rebuild of a failed data drive.

 

What I like about LVM is the ability to add a volume to a physical volume group.

migrate the volume and remove a physical volume from the volume group (the bad one).

 

This is what we need for the parity disk.

 

My thought here is, anytime you are buying a new disk.. you are probably buying a sweet spot or larger disk.

and I would think you may want to do a move of a parity disk to a larger one if available.

Thanks Joe, great ideas, much of which had not occurred to me.  I do see a problem with one part: I believe if unRAID formats the drive, the parity drive will also be modified, plus when un-assigning the drive, the parity drive will be invalidated.  We don't have an easy way to remove a data disk from an array, even if 'empty'.  Is there a way to get unRAID to prepare the drive with the array stopped?  Could there be a script of commands, or perhaps something added to UnMenu to provide these manual functions?  If nothing else, if someone could detail the Linux commands needed for partitioning, clearing, formatting...

 

What I would love to see is a 'Warm spare preparation' script or option, that would partition it, clear and format it, and run some form of burnin tests.  Actually, leaving it cleared and formatted may not be necessary, since it will probably be completely overwritten when put online, if it replaces a parity drive or is used to reconstruct a failed data drive.

 

Since we know a significant number of drives fail in the first month, I like to thoroughly test new drives before putting them online.  I want to 'encourage' them to fail during testing, rather than later in operation.  I now test by copying to and from a new drive a tree full of thousands of small files, several gigs worth, followed by several multi-gigabyte files, and file-compare the whole lot.  That tests drive, cable, and controller operation, but not the entire surface.  If unRAID or a script could write and check a couple of patterns across the entire surface, and then display the before and after SMART values, that would be much better, and would give a good indication of dependability of any drive.

 

Thanks Joe, great ideas, much of which had not occurred to me.  I do see a problem with one part: I believe if unRAID formats the drive, the parity drive will also be modified, plus when un-assigning the drive, the parity drive will be invalidated.  We don't have an easy way to remove a data disk from an array, even if 'empty'.  Is there a way to get unRAID to prepare the drive with the array stopped?  Could there be a script of commands, or perhaps something added to UnMenu to provide these manual functions?  If nothing else, if someone could detail the Linux commands needed for partitioning, clearing, formatting...

You are correct.  If you assign a drive and make it part of the array it does change parity.  When you un-assign it, you would have to use the "Restore" button to Save a new config with the currently assigned drives to get it to forget the drive.

 

You idea of a script of commands is a good one.

 

Basically, the commands needed are:

dd - to clear the drive

fdisk - to partition it

mkreiserfs  - to create a reiser file-system on the drive.

 

Then... you need mkdir to create an empty directory to use as a mount point, and mount to mount the drive

 

The danger of doing this is if you clear and format the wrong hard-disk, you've just lost your precious data.

 

Joe L.

If unRAID or a script could write and check a couple of patterns across the entire surface, and then display the before and after SMART values, that would be much better, and would give a good indication of dependability of any drive.

 

There is a program called badblocks that can be used to test a hard drive out.

You can run it in write mode on brand new drives to test them out.

 

There is also a program called shred that can be used to write patterns to files.(or a whole device)

My friend used this to re-map bad sectors by shredding the whole hard drive overnight.

 

 

What I would love to see is a simple disk migration strategy from the web front end that allows moving whole drives and expanding to another Disk.. This includes parity which is something you cannot do from the command line (at least I do not know how).

 

So at the very least if during a failure situation, you can migrate parity to a newer larger drive from a front end/command line.

Then that would satisfy the requirements to free up an older drive for rebuild of a failed data drive.

 

What I like about LVM is the ability to add a volume to a physical volume group.

migrate the volume and remove a physical volume from the volume group (the bad one).

 

This is what we need for the parity disk.

 

My thought here is, anytime you are buying a new disk.. you are probably buying a sweet spot or larger disk.

and I would think you may want to do a move of a parity disk to a larger one if available.

 

Good ideas.  Perhaps create a new web management tab called 'Advanced Operations'.  You don't want to confuse new users with new or technical or unnecessary options.

 

One idea I like is the ability to grow the parity disk without risking the existing parity drive.  Currently in order to move to a larger parity drive, you have to pull the current drive and rebuild parity onto the new drive.  If something goes wrong (and you don't have a copy of the super.dat), then you'll have to rebuild parity again.  If you have a copy of the flash drive, then you can restore it, and the old parity drive, and be back up with any changes.  With your idea, we can prepare a new parity drive by duplicating it to the new larger drive, then when ready, use a new option from Tom to move the parity assignment from one drive to the other, without the array ever being unprotected.  We would click on the 'Prepare new parity disk', then select the new drive from the standard disk assignment drop down menu, wait while the drive is mirrored from old parity drive to new one, then watch it re-assign the parity drives.  If anything goes wrong during this, nothing has changed, the old setup is still intact.  This is not a high priority feature, but adds some convenience and safety.