Upgraded to v6 - now want to add bigger drives

[walterg74]

Could be a bad drive I guess, but I think it's at least as likely to be a problem with something else. How old is your power supply? Power connections good anywhere there is a connection, not just at the drive? Have you done a memtest? Reseated cables AND controller in its motherboard slot?

 

Post a new diagnostic that includes this latest failure.

 

Power supply is not that old, and power connections seem fine everywhere else. it seems to be always this drive. Haven''t done a memtest now, I could of course do one, but why would that match up to the 1 drive?

 

Here is the new diagnostic attached, and screenie of what I see in main, which is what I saw when I checked again how the parity check was going  (again, after 12 hours of continuously working the pairty sync which came out fine..).

 

tower-diagnostics-20160103-1535.zip

[trurl]

No SMART on that drive in this latest either. Have you ever been able to get a SMART on that drive?

 

What is the exact model of your power supply?

[walterg74]

Yes, again no SMART, seems it tries to do it after the fact when it is no longer responsive? I was going to do a full SMART after the parity check completed, but... you know...

 

Power Supply is a Seasonic SS-650-AM

 

http://www.seasonicusa.com/M12II-Bronze-650-750-850.htm

 

Single rail 650W w/53A on the +12V rail.

[garycase]

Since the issues have all been with the SAME drive, I think it's time to replace it.

 

Although you haven't been able to fully check it and confirm it, the fact there were no errors during the parity sync means it's highly likely that you now have good parity -- so you can simply replace disk #6 without redoing your configuration.  [As long as you don't format the other drives, you'll still be able to do a New Config/Trust Parity to go back to the previous config if necessary -- but I don't think that will be the case]

 

Question:  If you access disk #6 to read data, does everything look okay?    The disk won't actually be read ... what you'll see is the results of emulation using the other disks plus the parity drive => but that's also exactly what you would have on a new disk if you do a rebuild.

 

I would NOT write anything to the array at this point.  But I WOULD replace disk #6 with a new disk and let it do a rebuild.  Now that you have a 3TB parity, you can replace #6 with another 3TB drive if you don't want to buy a small (1TB or 2TB) drive.

 

[walterg74]

Since the issues have all been with the SAME drive, I think it's time to replace it.

 

Although you haven't been able to fully check it and confirm it, the fact there were no errors during the parity sync means it's highly likely that you now have good parity -- so you can simply replace disk #6 without redoing your configuration.  [As long as you don't format the other drives, you'll still be able to do a New Config/Trust Parity to go back to the previous config if necessary -- but I don't think that will be the case]

 

Question:  If you access disk #6 to read data, does everything look okay?    The disk won't actually be read ... what you'll see is the results of emulation using the other disks plus the parity drive => but that's also exactly what you would have on a new disk if you do a rebuild.

 

I would NOT write anything to the array at this point.  But I WOULD replace disk #6 with a new disk and let it do a rebuild.  Now that you have a 3TB parity, you can replace #6 with another 3TB drive if you don't want to buy a small (1TB or 2TB) drive.

 

Ok, so if I try to read disk 6, all other disks spin up (of course) and what I see looks pretty much normal / what I expect, and same thing I saw yesterday when I backed up that disk to another location.

 

So what would be the way to proceed to jut replace it and bin that one? Like you say, with the 3TB parity I can use a 3TB which is what I have, *but* that disk I have is already assigned to the array (granted, it is in not formatted and umountable state). 

 

Can I do it fro where I am (see screenshot in my previous post) or would I have to go back?

[garycase]

You'll need a DIFFERENT drive than what you have in the array.    Your parity sync included all of the current disks; so you can't remove any of them except the one you need to rebuild.

 

You COULD try reconstituting the original array with the "Trust Parity" option -- BUT I would not recommend doing that, as if there is ANY issue with the original parity (remember all those sync errors) your rebuild wouldn't be successful => AND you could only use a 1TB drive for the rebuild, so you'd still have to buy another drive.

 

If you don't want to buy another 3TB drive, you can just buy a 1TB (or 2TB) drive and do the rebuild with it ... but you should do this SOON, as if anything else fails you'll lose the contents of both disk #6 and whatever else fails as well.    Personally, I'd shut down the array until you have a new drive, and then do the rebuild.

 

[walterg74]

You'll need a DIFFERENT drive than what you have in the array.    Your parity sync included all of the current disks; so you can't remove any of them except the one you need to rebuild.

 

You COULD try reconstituting the original array with the "Trust Parity" option -- BUT I would not recommend doing that, as if there is ANY issue with the original parity (remember all those sync errors) your rebuild wouldn't be successful => AND you could only use a 1TB drive for the rebuild, so you'd still have to buy another drive.

 

If you don't want to buy another 3TB drive, you can just buy a 1TB (or 2TB) drive and do the rebuild with it ... but you should do this SOON, as if anything else fails you'll lose the contents of both disk #6 and whatever else fails as well.    Personally, I'd shut down the array until you have a new drive, and then do the rebuild.

 

Last one seems like a good advice... I don't really want to buy another 1TB drive, as I'm trying to upgrade their sizes.

 

Now, if I did decide to "go back" (granted, I can yield to the advice to not cause problems needlessly, but weren't those errors due to the drive not being available?) why do you say I could only replace with a 1 TB drive? Couldn't I do the swap/disable as shown in the manual/wiki?

 

Edit: I *really* don't want to get a 1TB drive. Now the issue (just so you understand my frustration) is that where I live -Argentina-, prices are jacked up way too high. As an example, the same 3TB drive I get at Amazon for $90 costs about $300...  So I usually buy my stuff from the US when either I travel or one of my co-workers travels or one from the US comes here. Thing is nobody's coming or going In the near future...

 

If I were to pull a loaner 1TB from another computer, could I?:

 

- Replace the faulty 1 TB drive with that loaner

- Remove the unused (but currently part of the array) 3TB one

- Replace the loaner with the 3TB disk

 

Does that sound reasonable? I would be left with 1TB less than I was going to, but with a stable array to hold me off until I can get some more 3TB drive(s) at a reasonable price...

 

 

Edit2:  One other thing I may be missing... you had told me the following:

 

"I'd reseat the cables, then do a New Config with your current config and the "Trust Parity" option and see if you can access disk #4 okay => look at several of the files and see if they look okay and, better yet, copy the entire disk to another location so you have a current backup of its data.    Then I'd do yet-another New Config with ALL of your disks (including the new 3tB ones), and just let it do a new parity sync  [i.e. do NOT use the trust parity box]."

 

So having followed those steps, I'm thinking that the parity I have right now, with ALL the disks, was built with whatever was on disk 4 and the old parity disk anyway, is that not correct?  And of so, then what is the difference if I go back to the "old" smaller array then?

[trurl]

Are the unformatted drives clear? If so, they could actually be removed from the array without affecting parity.

[walterg74]

Are the unformatted drives clear? If so, they could actually be removed from the array without affecting parity.

 

Do you mean if I pre-cleared them? Of if I didn't write anything to them?

 

Of the unformatted ones, the small 1TB one is the old parity drive, and the 3TB one is one of the new drives which was only pre-cleared and added to the array  (and nothing written to the array since).

 

 

[trurl]

Seems like you should be able to New Config / Trust Parity without the precleared 3TB and then assign it in place of the failed drive and rebuild. Might wait for a second opinion on that but I think it should work.

[walterg74]

Seems like you should be able to New Config / Trust Parity without the precleared 3TB and then assign it in place of the failed drive and rebuild. Might wait for a second opinion on that but I think it should work.

 

Ok, out of your own keyboard will wait for that second opinion

 

So when you start the array and select "trust parity", basically you say "everything I have is OK". But with my missing/faulty drive wouldn't that cause issues?  I though before I was told even though unformatted it was still taken into account to do the parity sync I had completed?

 

[trurl]

Seems like you should be able to New Config / Trust Parity without the precleared 3TB and then assign it in place of the failed drive and rebuild. Might wait for a second opinion on that but I think it should work.

 

Ok, out of your own keyboard will wait for that second opinion

 

So when you start the array and select "trust parity", basically you say "everything I have is OK". But with my missing/faulty drive wouldn't that cause issues?  I though before I was told even though unformatted it was still taken into account to do the parity sync I had completed?

All trust parity really does is keep unRAID from rebuilding parity against the assigned drives. You already have parity built and you have already determined that it could rebuild your disk by reading the emulated disk.

 

Since the new 3TB is clear (all zeros), it actually has no affect on the parity calculations, so whether it is in the array or not shouldn't matter to the result of those calculations, which includes the case where parity is used to calculate the data for the rebuild.

 

You could actually check that this will work by doing New Config/Trust Parity and Start, Stop and unassign the failed disk, Start and see if you can read the emulated disk like before.

 

I should probably mention that a lot of what I say in these situations doesn't come from personal experience, it just comes from understanding how parity works. A lot of these questions answer themselves if you understand that.

 

I would still wait on a second opinion in case there is some detail about assigning a clear drive that makes it no longer really clear, but according to your screenshot there were no writes to that drive.

[walterg74]

So meanwhile I checked and on a second computer I have a 1 TB drive installed, that I could take put, backup to an external disk and use it as the loaner... I would just donthat backup tomrestore it quick later, since it's just games that -if lost- I can just re-install...

 

Would yo pu say I just go ahead and use that to do what I said above? (Repace faulty 1TB,remove unused 3TB from array, replace loaner with currently unised 3TB).

 

If so, does it make sense to pre-clear that deive, or since it will ne just used for this it wouldn't rewlly be necessary?

[trurl]

The only time a disk must be clear is when it is added to a new slot in a parity array. This is so parity will remain valid. A drive that will rebuild another drive doesn't have to be clear, but it does have to be reliable, perhaps more reliable than it did in its former usage. Can you get a SMART report for it?

[JorgeB]

I didn’t read the entire thread but I can confirm that adding a precleared disk and then removing it has no effect on parity, I did actually test this a while ago on my test server.

[garycase]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

Bottom line:  I don't know for sure, but personally I would NOT trust my data to that process.

 

Given your current situation, I'd do the following:

 

(1)  With a "loaner" 1TB drive, replace the failed drive and let UnRAID rebuild the data onto the new drive.

 

(2)  Now do a New Config with everything EXCEPT the newly rebuilt 1TB drive. and let the system do a new parity sync.      When that's done, do a parity check to confirm all is well; then let it format old parity and 2nd 3TB drive.

 

(3)  Mount the 1TB drive you had rebuilt the failed drive on outside of the array, and copy all of the data from it to the array [You'll have lots of space, since you just added 4TB of storage space.]

 

(4)  Now you can return your "loaner" drive 

[garycase]

... AND you should definitely keep a couple spare drives, given the big cost differential you have to contend with for local purchases.

 

[walterg74]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

Bottom line:  I don't know for sure, but personally I would NOT trust my data to that process.

 

Given your current situation, I'd do the following:

 

(1)  With a "loaner" 1TB drive, replace the failed drive and let UnRAID rebuild the data onto the new drive.

 

(2)  Now do a New Config with everything EXCEPT the newly rebuilt 1TB drive. and let the system do a new parity sync.      When that's done, do a parity check to confirm all is well; then let it format old parity and 2nd 3TB drive.

 

(3)  Mount the 1TB drive you had rebuilt the failed drive on outside of the array, and copy all of the data from it to the array [You'll have lots of space, since you just added 4TB of storage space.]

 

(4)  Now you can return your "loaner" drive 

 

Wait... Probably me being slow but don't understand 100%...

 

(1)  With a "loaner" 1TB drive, replace the failed drive and let UnRAID rebuild the data onto the new drive.  -------> Perfect I will just physically install this loaner drive and assign it in the bad ones place. letting unraid rebuild it.

 

(2)  Now do a New Config with everything EXCEPT the newly rebuilt 1TB drive. and let the system do a new parity sync.      When that's done, do a parity check to confirm all is well; then let it format old parity and 2nd 3TB drive. --------> For this you mean also without the failed drive of course, right? So after these steps, what I would actually be doing is creating a new array with only the data of the other good 3 1TB disks  (plus whatever it reads fro the unformatted 3TB+1TB of course). Is that correct?

 

(3)  Mount the 1TB drive you had rebuilt the failed drive on outside of the array, and copy all of the data from it to the array [You'll have lots of space, since you just added 4TB of storage space.]

(4)  Now you can return your "loaner" drive  --------> So here just re-adding the "old stuff" to the "new array"... Right?

 

Now, one quick question... If that is the case, and what I am doing is taking the data from all these "good" drives (because the rebuild onto the loaner will simply use the data from all the good disks), and the process of creating a new config simply creates new parity from all these "good drives" into a new array....  Being that right now I can read the contents of disk 4 just fine (from the other disks of course) and that this would be exactly the same data I would rebuild on the loaner...

 

Why can't I just copy right now everything off my "virtual" failed disk, and then just do step 2, eliminating the need for the loaner completely?

 

 

 

[walterg74]

... AND you should definitely keep a couple spare drives, given the big cost differential you have to contend with for local purchases.

 

Yes, I will definitely do this... My brother is going to India this month, and while the price isn't *just* as good as the US, it's very very close (rught now amazon US has the drives I bought for $89.99 but plus tax, so ~$97-98 and amazon India has it for about $115, a difference I can definitely live with... Will ask him to bring back a pair or three...

 

[JorgeB]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

I believe that is it, as I did a parity check before adding disk with 0 sync errors, added precleared disk, started array, stopped array, did a new config with all the same disks except the precleared one, parity check complete with 0 sync errors.

 

I then tried adding the same disk a second time, the disk is not recognized as precleared anymore, i.e., the special signature was deleted when added the first time, but doing a new config and this time including the precleared disk resulted again in 0 zeros after parity check.

 

 

 

[Squid]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

I believe that is it, as I did a parity check before adding disk with 0 sync errors, added precleared disk, started array, stopped array, did a new config with all the same disks except the precleared one, parity check complete with 0 sync errors.

 

I then tried adding the same disk a second time, the disk is not recognized as precleared anymore, i.e., the special signature was deleted when added the first time, but doing a new config and this time including the precleared disk resulted again in 0 zeros after parity check.

unRaid would have zeroed out the signature when it added it to the array (since it was no longer recognized as being precleared).  Only way this would have worked.  Also means that the area of the signature is protected by parity.

[JorgeB]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

I believe that is it, as I did a parity check before adding disk with 0 sync errors, added precleared disk, started array, stopped array, did a new config with all the same disks except the precleared one, parity check complete with 0 sync errors.

 

I then tried adding the same disk a second time, the disk is not recognized as precleared anymore, i.e., the special signature was deleted when added the first time, but doing a new config and this time including the precleared disk resulted again in 0 zeros after parity check.

unRaid would have zeroed out the signature when it added it to the array (since it was no longer recognized as being precleared).  Only way this would have worked.  Also means that the area of the signature is protected by parity.

Good point,  this makes more sense.

[JorgeB]

r.e. a pre-cleared disk ==> A pre-cleared disk is NOT all zeroes ... it has a special signature the identifies it as having been pre-cleared.    If you remove it from the array and "trust parity", the parity bits associated with the area where the signature is will be incorrect.

 

On the other hand, Johnnie's experiment apparently did not find any parity errors on an array where he tired this -- so it may be that the pre-clear signature is "outside" of the area that's protected by parity.

 

I believe that is it, as I did a parity check before adding disk with 0 sync errors, added precleared disk, started array, stopped array, did a new config with all the same disks except the precleared one, parity check complete with 0 sync errors.

 

I then tried adding the same disk a second time, the disk is not recognized as precleared anymore, i.e., the special signature was deleted when added the first time, but doing a new config and this time including the precleared disk resulted again in 0 zeros after parity check.

unRaid would have zeroed out the signature when it added it to the array (since it was no longer recognized as being precleared).  Only way this would have worked.  Also means that the area of the signature is protected by parity.

Good point,  this makes more sense.

 

One more thing, I also added precleared disks to an array by doing a new config and this also does not change parity, after starting the array once these disks can no longer be added to a existing array, they stop being identified as precleared, I believe this means the special signature is deleted anytime a precleared disks is used on an array.

[garycase]

... Why can't I just copy right now everything off my "virtual" failed disk, and then just do step 2, eliminating the need for the loaner completely?

 

You CAN do this, with one IMPORTANT caveat => Do NOT do these copies using user shares ... copy them from the disk share [i.e. reference them via the disk (\\Tower\disk6\...) and NOT via a share].    You can copy the data to a new share if you want ... i.e. "D6Data" that excludes the failed disk.

 

Then you can indeed completely skip the loaner step 

[walterg74]

... Why can't I just copy right now everything off my "virtual" failed disk, and then just do step 2, eliminating the need for the loaner completely?

 

You CAN do this, with one IMPORTANT caveat => Do NOT do these copies using user shares ... copy them from the disk share [i.e. reference them via the disk (\\Tower\disk6\...) and NOT via a share].    You can copy the data to a new share if you want ... i.e. "D6Data" that excludes the failed disk.

 

Then you can indeed completely skip the loaner step 

 

Ok, so while waiting for a response, that is exactly what I did yesterday. Opened up \\tower\disk6 and copied everything off that.

I the. Compared amount of files and sizes, and testes a few pictures and videos/movies.

Since Inalsonhad a lot of zipped files also checked some of those for errrors. Everything seemed to be fine, son I guess that's as good as it gets.

 

So then next step is:

 

- Create new config with all currently installed disks except the bad one and let it recreate parity

- Do parity check

- Copy back the contents of what I backed up yesterday into the appropriate shares now

- Done

 

Right?

 

One thing I can't shake is that the "bad" disk seems to be OK after powering down and back up again... Something like of the errors were just cause by the disk dissapearing to the system like if it had lost power. I guess Incould always leave it outside the array and try it on a different data/power port too? (After doing the above and having a stable array first of course..)