Hi

 

First-time poster but fairly long-time user of unRAID (4 or 5 years, and loving it!)

 

I've come across a situation which I think means I should probably use the swap-disable method, but I wanted to get some advice before I plunged in head-first. My situation is this.

• Running unRAID Server Pro version 5.0-rc5
  
• I have 11 data disks, a 500GB cache disk and a 2TB parity, but was about to upgrade to a 3TB parity
  
• After a clean boot and parity check I have one drive (a 1TB Samsung disk) with 924 in the Errors column in the unRAID Main screen
  
• This disk has generally had some errors showing for the last few months, and I've bought a 3TB to replace it too (which is why I'm upgrading my parity first)
  
• smartctl for the disk in question shows 171 for Current_Pending_Sector
  

It's my understanding that the Errors column indicates read errors (not write errors - my drive is still green-ball). The non-zero Current_Pending_Sector count looks like it indicates read errors too. Which presumably means that I have some bad sectors that might be remapped by the disk on write, but I haven't written to them yet so they haven't been reallocated. My read attempts haven't actually failed to deliver the data due since they can be satisfied by parity. However, if I put a blank parity disk in and try to recompute fresh parity, presumably it won't be able to fill in those gaps any more, thus leaving me with lost data and potentially corrupted files. Since my replacement disk is bigger than my parity, I think that swap-disable seems appropriate. But as I said, the failing drive is not actually red-balled at this point.

 

So my main question is: Can I use the "swap-disable" procedure when my "failed" disk is still green-balled? And should I, or is there a better (safer or just easier) approach in this situation?

 

An important secondary question: I saw some forum posts indicating that swap-disable was fixed in 5.0-rc11, though I'm not sure when it got broken. Since I'm using RC5, should I upgrade to RC11 first (and would you consider it safe to upgrade when such errors are present?) Or does RC5 have a functional swap-disable feature?

 

Note, I read about the swap-disable method in the "Replace a failed disk" section of the Un-Official unRAID docs (http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Replace_a_failed_disk).

 

BTW, the community support for unRAID is so excellent that my main reason for not posting during the last few years is that I haven't needed to - all the answers have already been there when I needed them! And, I realise that I haven't included my syslog, but at this point I'm just asking for advice before I take action, rather than trying to solve an immediate problem. I'm happy to add one though, if it will help.

 

Thanks,

-- tallorder

Hi

 

First-time poster but fairly long-time user of unRAID (4 or 5 years, and loving it!)

 

I've come across a situation which I think means I should probably use the swap-disable method, but I wanted to get some advice before I plunged in head-first. My situation is this.

• Running unRAID Server Pro version 5.0-rc5
  
• I have 11 data disks, a 500GB cache disk and a 2TB parity, but was about to upgrade to a 3TB parity
  
• After a clean boot and parity check I have one drive (a 1TB Samsung disk) with 924 in the Errors column in the unRAID Main screen
  
• This disk has generally had some errors showing for the last few months, and I've bought a 3TB to replace it too (which is why I'm upgrading my parity first)
  
• smartctl for the disk in question shows 171 for Current_Pending_Sector
  

It's my understanding that the Errors column indicates read errors (not write errors - my drive is still green-ball). The non-zero Current_Pending_Sector count looks like it indicates read errors too. Which presumably means that I have some bad sectors that might be remapped by the disk on write, but I haven't written to them yet so they haven't been reallocated. My read attempts haven't actually failed to deliver the data due since they can be satisfied by parity. However, if I put a blank parity disk in and try to recompute fresh parity, presumably it won't be able to fill in those gaps any more, thus leaving me with lost data and potentially corrupted files. Since my replacement disk is bigger than my parity, I think that swap-disable seems appropriate. But as I said, the failing drive is not actually red-balled at this point.

 

So my main question is: Can I use the "swap-disable" procedure when my "failed" disk is still green-balled? And should I, or is there a better (safer or just easier) approach in this situation?

No, the process will not work unless you actually have a disabled or missing disk.

 

An important secondary question: I saw some forum posts indicating that swap-disable was fixed in 5.0-rc11, though I'm not sure when it got broken. Since I'm using RC5, should I upgrade to RC11 first (and would you consider it safe to upgrade when such errors are present?) Or does RC5 have a functional swap-disable feature?

 

Note, I read about the swap-disable method in the "Replace a failed disk" section of the Un-Official unRAID docs (http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Replace_a_failed_disk).

 

BTW, the community support for unRAID is so excellent that my main reason for not posting during the last few years is that I haven't needed to - all the answers have already been there when I needed them! And, I realise that I haven't included my syslog, but at this point I'm just asking for advice before I take action, rather than trying to solve an immediate problem. I'm happy to add one though, if it will help.

 

Thanks,

-- tallorder

Your best bet is to attempt to get unRAID to re-construct the sectors needing reconstruction before doing anything else.

 

I would preclear both of the new 3TB drives, assign each in turn as the "CACHE" drive, formatting each as the CACHE drive.  Then, you can assign your original cache drive back.  This will partition and format the disks for unRAID's use without changing your protected array in any way.

 

Then, I'd mount one of the 3TB drives to a mount-point (an empty directory) you create.

mkdir /mnt/temp_disk

# then mount the first partition (note the trailing "1") of the new 3TB disk on the mount point.  Again, you'll need to use the device name of your 3TB disk.

mount -t reiserfs /dev/sdX1 /tmp/temp_disk

 

# then copy from the bad disk (letting it reconstruct as it goes) to the temporary copy.

# for this example, I'm assuming it is disk9 that is defective.  Change the disk number when you use

# this command to that of your failing disk.

cp -R -v /mnt/disk9 /tmp/temp_disk

 

This copy process will take a number of hours, depending on how much data is to be copied from the old disk to the new.

 

Once the copy is complete, you should have a good copy of your data on the new 3TB disk.  At that point you can un-mount the newly loaded data drive

umount /tmp/temp_disk

 

Stop the array, assign the newly loaded data disk in place of the failing disk.  (keep te failing disk aside, as it has a copy of its data if you really have bad luck)    You can also assign the other 3TB drive in  place of the parity disk (again keeping it aside for now), then  use the "Utils->New-Config" to set a new disk configuration and start the array

 

It should calculate parity on the newly configured array and once completed you'll have the 3TB parity and the 3TB data disk in place.

 

Don't do anything until you have a safe copy of the disk that is failing.  Make backup copies of anything precious.  Make a copy of the config directory on the flash drive once you first stop the array before changing any disk assignments.  This will let you get back to the original config if absolutely necessary with your old parity and old data disk..

 

Joe L.

Make a copy of the config directory on the flash drive. Then, I would just un-assign the failing disk and then start and stop the array. The array will now red-ball the missing disk and you can now assign your 3T drive as parity and assign the old parity as disk9. Hit start and it will fix-up both.

 

If you have the copy of the config directory before you start then you can put the array back like it presently is if you have an issue updating.

 

As for your question on the swap-disable being broken. I don't know when it was broken or when it was fixed. Either RC8 or RC9 was around for a long time and there were no reports of it being broken so I suspect it was OK up to that point and it got broken in RC10.

 

 

"... This disk has generally had some errors showing for the last few months ..."  ==>     Definitely risky to let a known-failing drive stay in the array for months !!    The most important thing is, as JoeL noted, be sure you have a copy of all the data on the disk before you replace it.    The simplest thing to do would have been to simply replace the bad disk with a new 2TB drive, so it could rebuild with the existing parity drive.    But if you don't want to do that, the process Joe outlined will work fine.

 

Hi

 

Thanks heaps lionelhutz and garycase, and especially Joe L. for the detailed follow-up. Using the cache disk slot to format the drives then manually copying the data disk to make use of parity wasn't an approach I had even remotely considered, so I'm really glad I checked here before doing anything! And now that you've pointed it out it seems a really sensible way of truly minimising my "unprotected" window to a parity rebuild only, while eliminating the threat of those dodgy sectors! Definitely something I'll keep in mind for future problems.

 

I realised after I grabbed the 3TB drives that replacing the failed one with a 2TB would have been easier, but my chassis is nearly full so I'm trying to maximise my density with large drives, and 3TB drives are finally cheaper locally per TB than 2's now, so I'd have probably made the same decision anyway.

 

As to how I can run for a couple of months with errors showing and still manage to sleep at night? All I can say in my own defence is that I have a baby daughter, so sleeping at night already ain't what it used to be

 

(That said, all my critical folders like photos etc and even my flash drive are mirrored locally and in the cloud thanks to CrashPlan. So I'm trying to avoid the irritation of recovery from those sources, rather than an epic disaster!)

 

I'll give this plan a go and report back later in the week.

 

Thanks again,

-- tallorder

Make a copy of the config directory on the flash drive. Then, I would just un-assign the failing disk and then start and stop the array. The array will now red-ball the missing disk and you can now assign your 3T drive as parity and assign the old parity as disk9. Hit start and it will fix-up both.

 

If you have the copy of the config directory before you start then you can put the array back like it presently is if you have an issue updating.

 

As for your question on the swap-disable being broken. I don't know when it was broken or when it was fixed. Either RC8 or RC9 was around for a long time and there were no reports of it being broken so I suspect it was OK up to that point and it got broken in RC10.

 

dont think this will work as there is no "parity" to reconstruct disk9 from.

 

Joe L has the right method to fix this and move your array forward.

Make a copy of the config directory on the flash drive. Then, I would just un-assign the failing disk and then start and stop the array. The array will now red-ball the missing disk and you can now assign your 3T drive as parity and assign the old parity as disk9. Hit start and it will fix-up both.

 

If you have the copy of the config directory before you start then you can put the array back like it presently is if you have an issue updating.

 

As for your question on the swap-disable being broken. I don't know when it was broken or when it was fixed. Either RC8 or RC9 was around for a long time and there were no reports of it being broken so I suspect it was OK up to that point and it got broken in RC10.

 

dont think this will work as there is no "parity" to reconstruct disk9 from.

I think it would, but would take longer.  Parity is first copied from the old parity disk to the new, and then the failing disk re-constructed.  It is a special process named "swap disabled"  (the key being the disk to be replaced is already disabled and the new disk is larger than the current parity disk)

Joe L has the right method to fix this and move your array forward.

The process I described (formatting and using one of the new 3TB drives to make a copy of the failing disk) will minimize the unprotected window of time, AND it will let you revert back to the original parity disk and data disk if one of the new replacement were to fail in the middle of the process. (as long as you made a copy of the "config" directory.)

Make a copy of the config directory on the flash drive. Then, I would just un-assign the failing disk and then start and stop the array. The array will now red-ball the missing disk and you can now assign your 3T drive as parity and assign the old parity as disk9. Hit start and it will fix-up both.

 

If you have the copy of the config directory before you start then you can put the array back like it presently is if you have an issue updating.

 

As for your question on the swap-disable being broken. I don't know when it was broken or when it was fixed. Either RC8 or RC9 was around for a long time and there were no reports of it being broken so I suspect it was OK up to that point and it got broken in RC10.

 

dont think this will work as there is no "parity" to reconstruct disk9 from.

 

Joe L has the right method to fix this and move your array forward.

 

Yes, it will work. There is a parity drive. It's get reconsructed onto the new drive and then used to rebuild the data disk onto the old drive.

 

I don't see any more risk either way but doing the swap disable is much simpler to follow. Save the config before starting and you can also put the old parity back if needed.

Well I ended up using Joe L's method and it has worked fine, my parity rebuild is progressing now and my array is available (although currently unprotected), with all the data appearing where it should. Although forcing a swap-disable might have worked too, something appealed to me about having manually copied my data onto the new disk, and I'm not too fussed by the extra few steps (plus, the steps feel a bit more under my direct control - forcing a red-ball feels like I'd be "tricking" unRAID somehow!) And skipping the initial parity clone keeps that unprotected window small (especially important for me since my parity rebuild takes over a day).

 

Anyway it's all looking good, so thanks again for all your help. Hope this thread can help someone else in the future too - it seems like a not uncommon situation to want to replace a disk that's showing read errors before it goes red-ball, using disks that are bigger than your parity.

 

-- tallorder

Make a copy of the config directory on the flash drive. Then, I would just un-assign the failing disk and then start and stop the array. The array will now red-ball the missing disk and you can now assign your 3T drive as parity and assign the old parity as disk9. Hit start and it will fix-up both.

 

If you have the copy of the config directory before you start then you can put the array back like it presently is if you have an issue updating.

 

As for your question on the swap-disable being broken. I don't know when it was broken or when it was fixed. Either RC8 or RC9 was around for a long time and there were no reports of it being broken so I suspect it was OK up to that point and it got broken in RC10.

 

dont think this will work as there is no "parity" to reconstruct disk9 from.

 

Joe L has the right method to fix this and move your array forward.

 

Yes, it will work. There is a parity drive. It's get reconsructed onto the new drive and then used to rebuild the data disk onto the old drive.

 

I don't see any more risk either way but doing the swap disable is much simpler to follow. Save the config before starting and you can also put the old parity back if needed.

 

But if parity is new and disk9 is new how does this work? If done 1 at a time then I could see how this works (disk9 rebuild then new parity) but otherwise isn't parity gone when you assign Parity to Disk9 and put new parity in. The contents of disk9 cannot be rebuilt without valid parity and since it was moved to disk9 its gone??

 

The swap-disable approach seems to be a special mode to address the (probably pretty common) scenario where you want to replace a failed disk with a new one but the new drive you've bought is bigger than your parity. Normally a double-replacement wouldn't be possible. But with swap-disable it copies the parity data from the old parity disk to the new one first, THEN does a rebuild of the new data disk... looks to be kind of equivalent to doing two separate single-disk replacements, one after the other, automatically. There's a link in my first post but the relevant section reads:

 

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.

 

But you have to be in exactly the right scenario to take advantage of it, and in my case I wasn't because my disk had a few read errors but hadn't actually failed as far as unRAID was concerned. I thought I might be able to use swap-disable but I didn't meet the precise conditions, so I didn't end up using that feature this time around.

 

-- tallorder

ok i see now.

 

didnt know that was a "feature".

 

thanks!