Array Trust Procedure on 5.x betas

[Roancea]

So, just want to confirm what I've skimmed from assorted threads from the last few months. 

 

Reading through everything here, it doesn't appear as if there's really a "trust my array" procedure anymore for the 5b series - the mdcmd set invalidslot 99 apparently doesn't work any more, correct?

 

So, when I bumped a cable loose (array was idle, not writing) and had a drive red ball on me, please tell me if there's any other option than:

 

unassign drive

restart array

stop array

reassign drive

rebuild drive

 

If that's the case, what would one do now under the 5 betas if for whatever reason you had a similar issue with more than 1 drive?  In that situation, you can't rebuild, and there doesn't seem to be a way to just tell unraid to accept the array anymore?  Am I missing something?

[Joe L.]

It is broken.

 

Not sure of the proper procedure, but basically if you can do it all fro the command line it should work.

 

You just cannot refresh the management page, is it reloads the device driver and negates the set invalidslot.

 

I think (but have not verified) that if you type:

/root/mdcmd set invalidslot 99

/root/mdcmd check

 

It should think parity is correct and just start a parity check.  If you get an error

md: check_array: invalid option:

you must supply an additional parameter as described below.

 

Note: In newer releases of unRAID, you must specify the type of parity check

/root/mdcmd set invalidslot 99

/root/mdcmd check NOCORRECT

 

Joe L.

[Roancea]

Joe, you're always helpful and always prompt. Thanks so much for that info, I'll keep it in mind for next time as I'm already halfway through rebuilding and I'm not thinking it would be a great idea to stop it partway through.

[Athuruga]

Hi I wanted to move from 5 RC 3 to RC 5.

I started the server but it did not come up and I had to shut it down.

I replaced the the files bzimage and bzroot again with rc3 files, but after that my drive 4 came up with a red ball.

I tried this procedure starting the server stopping the array.

 

Per Telnet I used Initconfig, and then

/root/mdcmd set invalidslot 99

this worked so far, but when I try

 

/root/mdcmd check NOCORRECT

I get

/root/mdcmd: line 11: echo: write error: Invalid argument

 

Now all of my 8 discs (1 Parity and 1 Cache) are unassigned and I'm affraid in loosing all my data.

 

What do I need to do to get them online again please help me!?

 

 

[smegger68]

Can we get some clarification on this? I keep getting redball drives, always on disk 4 despite having changed the drive twice, the sata cale and the PSU in my server. I guess it's a RC5 issue, but having to redo parity (a 27 hour operation) every time it happens is becoming very tedious. The procedure listed in this thread doesn't work, I get the same issue as Athuruga, when I type:

 

/root/mdcmd check NOCORRECT

I get

/root/mdcmd: line 11: echo: write error: Invalid argument

 

and have to start a parity check all over again. Any chance of a 'Trust array' button sometime soon?

[lordnimon]

Bumping this.  Anyone else having trouble getting the trust procedure working on rc6 test 2?  I'm getting the same issue as smegger68.

 

[Joe L.]

Bumping this.  Anyone else having trouble getting the trust procedure working on rc6 test 2?  I'm getting the same issue as smegger68.

Basically, the procedure DOES NOT work as it used to.  mdcmd was re-written in the 5.0 series to not return any response,so you are blind to its effect.

Do NOT refresh the web-browser.... That will guarantee it will fail.

 

Joe L.

[dgaschk]

The latest versions have a "parity is correct" checkbox when starting the array after using the "New Config" utility.

[lordnimon]

Thanks for the info.  The "parity is correct" checkbox is the only way I could get it to work.  The only downside is having to reassign 24 drives separately which you didn't have to do before with the old method.

[Joe L.]

Thanks for the info.  The "parity is correct" checkbox is the only way I could get it to work.  The only downside is having to reassign 24 drives separately which you didn't have to do before with the old method.

I feel you should still perform a parity check.  When you bumped a cable the next "write" to the drive failed.  (The unRAID OS does not take it out of service until it next attempts to use the drive)  That "sailed write" took it out of service.  Since one "write" failed," the disk you trusted may not have the contents you expect.  The "write" might just be housekeeping (marking the mount-date-time-stamp) or it could be anything else.  In any case, parity was updated,but the data disk was not.  For that,they might be out-of-sync.  A parity check might find a few differences.

 

I would also perform a file-system check on the drive that was accidentally disconnected just to make sure the failed write did not corrupt the file system on it.

 

Joe L.

[lordnimon]

When you tick "Parity is correct" and start the array, it automatically initiates a parity check.  There were some early corrections made, but none after that.  I think a 2 port jmicron controller card is causing issues, it randomly drops out even when the drive is just idling (no reading or writing) and causes a red balled drive.  The drive is only marked with a red red ball after a reboot though.  It stays green and the read/write IO count goes astronomically high and just keeps rising until the reboot.  I've replaced the card and will see if the problem continues to occur.