December 25, 201213 yr First off: Everything is fine, just wondering why this happened? Dec 25 09:05:20 Tower emhttp_event: svcs_restarted Dec 25 09:05:53 Tower kernel: mdcmd (28): clear Dec 25 09:05:58 Tower kernel: mdcmd (29): check NOCORRECT <- was this my doing? Dec 25 09:05:58 Tower kernel: md: recovery thread woken up ... Dec 25 09:05:58 Tower kernel: md: recovery thread syncing parity disk ... Dec 25 09:05:59 Tower kernel: md: using 1536k window, over a total of 1953514552 blocks. I just upgraded from 5.0-beta3 to 5.0-rc8a Reboot your server. Once boot-up has completed, you should see "Stopped. Configuration valid." array status with all disks assigned correctly except for the Cache disk. If you previously had a Cache disk assigned, you will need to re-assign it manually and re-apply any unique configuration settings for it. When I restarted no disk had been assigned? So after I resigned all disk, I hit start... It told me Parity is invalid/Yellow Ball? I quickly opened up each disk to see if everything was good.. everything was all good.. So I decided to run a parity sync.. so why did this happen? The only thing, I'm thinking is there was a box that said parity is valid.. that I did not click? But that does't seem to make much sense, that would seem to me. That the parity drive is valid.. and nothing is wrong? Do not check? So now it's rewriting the whole parity disk.... I'm not to worried "minus" drive failure in next 281 minutes lol If I had clicked parity valid, would it just have started up normal? I know it sounds like it should, but that just seems like it's saying parity sync is good? No need to rebuild the whole drive?
December 25, 201213 yr since you reassigned every drive, unraid didn't know, if the parity is still valid. (if you assigned the drives in a different order, the parity would not be valid. if you used the same order as before, you could have clicked on "parity is valid")
December 25, 201213 yr Author since you reassigned every drive, unraid didn't know, if the parity is still valid. (if you assigned the drives in a different order, the parity would not be valid. if you used the same order as before, you could have clicked on "parity is valid") okay so user error, but why did I have to reassign the drivers?
December 25, 201213 yr You should not have had to re-assign the disks. Data drives can be assigned in any order and parity is still good. You could have checked parity is valid and then done a parity check to make sure.
December 26, 201213 yr if you assigned the drives in a different order, the parity would not be valid.Not true. Parity is calculated as a sum of the bits in the drives column at a specific address. The transitive property applies to the bit addition, so switching (1 + 0 + 1) = Even parity to (0 + 1 + 1) also = Even parity. Or something like that.
December 26, 201213 yr Author well everything worked just fine Dec 25 15:33:57 Tower kernel: md: sync done. time=23278sec Dec 25 15:33:57 Tower kernel: md: recovery thread sync completion status: 0
December 26, 201213 yr well everything worked just fine Dec 25 15:33:57 Tower kernel: md: sync done. time=23278sec Dec 25 15:33:57 Tower kernel: md: recovery thread sync completion status: 0 Was that for the parity build, or the subsequent non-correcting check that you ran manually?
Archived
This topic is now archived and is closed to further replies.