[SOLVED] start array without Rebuilding parity in 5.0.5?

[DonkeyDon]

Hi,

 

I found a few posts regarding this subject, highlighting differnces in version 6, and whats different for version 4.7, and earlier.  Being between on version 5.0.5 today, I wanted to ask specifically for my situation.

 

My problem started while I was moving my existing drives, one by one into a new 5 in 3 trayless cage, and running a parity verification in between each swap to make sure each drive worked properly, before I got 5 drives  jumbled together.  After the 3rd swap, I had an issue where the array wouldn't start( drive2 aka sdg was absent, resulting in the red square DISK_DISABLE_NP. So I shut down, and I replaced the cable.  Upon power up, got the blue dot and assigned the drive to same array slot. 

 

I believe there's no real problem with any of the drives at this point.

 

Now, I want to restart the array, and run parity without corrections, just to make sure I don't have any other problems, before i go writing anything to what should be an error-free array, but my screen only shows Start as "bring array online and Rebuild parity",  But I definitely don't want to rebuild parity until I'm double sure I've got all the drives where they belong, and fully operaional.  My screen only offers me the options in the screenshot below..

 

so how can I safely just start the array and only verify parity without writing to the array?

 

 

 

 

Thanks in advance !

Don

Edited October 22, 2017 by DonkeyDon
mark as solved

[JorgeB]

Take a screenshot of current assignments then go to Utils -> New Config

 

Then reassign all disks and check "parity is already valid" before starting the array.

[tdallen]

There was a period of time when the "parity is valid" feature was broken.  Johnnie, was it working with 5.05?

[JorgeB]

13 minutes ago, tdallen said:

was it working with 5.05?

 

Yes

[DonkeyDon]

I did the above and as it started the parity verify , I immediately got 1007 errors, and 106 writes to the array as shown below.   These numbers stayed steady for about an hour, before I let the verifying continue while i slept.  Now at 49% with 1381 errors.

 

Another oddity, is that there is no syslog except, for one line showing the restart.  This is odd, because when I saw the initial errors, I check the syslog last night, and it showed that they happened in the first 1-2 secs of the scan. I check the flash/logs directory, and there is no files there for this restart of the server, based on timestamp of when i know i restarted it

 

also there was one disk error, which I believe  happened before this reboot, when the cabling was questionable.

 

This is my backup server, meaning I don't have a backup of it. So is there an easy way to tell which files on disk2 correspond to the parity errors? if not, how should i proceed?

 

[JorgeB]

31 minutes ago, DonkeyDon said:

So is there an easy way to tell which files on disk2 correspond to the parity errors?

 

Only if you have checksums, if not only way would be to compared them with the ones from the other server, note also that a few sync errors don't mean there is file corruption for sure, they can be related to filesystem housekeeping.

 

35 minutes ago, DonkeyDon said:

if not, how should i proceed?

 

If you don't have checksums and it's not easy to compare the files with the other server best bet would be to correct the sync errors.

 

Also you should upgrade to v6.

[DonkeyDon]

I  actually had been planning to build a version 6 box, separate from this one, after i finished consolidating. I did the same thing when i upgraded from 4.7,   i've always felt safer copying files to  an up-and-running box, rather than fiddling with the box containing my data,  

 

Before correcting parity, I may replace disk2 with a new.blank drive, then reconstruct disk2 data, then compare the reconstructed files to what's currently on the old drive(mounted as a single non-array disk). At least then, i can isolate the "known good" files from the suspect ones. Bad idea? 

 

 

[JorgeB]

11 minutes ago, DonkeyDon said:

At least then, i can isolate the "known good" files from the suspect ones. Bad idea? 

 

It's an option, you can then run a compare between both disks, all files that match can be considered good, with some luck most, maybe even all, will match.

 

Another easy option, as long as this backup server is a mirror of another, would be to have rsync compare checksums on all files, but it would take a long time.

 

It's because of these and other similar situations that I recommend always having checksums for all files (or using an auto-checksum filesystem), they are invaluable for checking data integrity.

[DonkeyDon]

 

Just now, johnnie.black said:

It's because of these and other similar situations that I recommend always having checksums for all files (or using an auto-checksum filesystem), they are invaluable for checking data integrity.

 

 

Agreed.  Iwent looking for somthing like his when i first got on unraid, but didn't find much that would stay sync'd.  But I definitely haven't kept current with what tools are available.  Can unRaid 6 use  an autochecksum file system like you are describing?  if not, what tools do you use for checksums?

[JorgeB]

Btrfs does autochecksums and it's an option with v6, there's also the dynamix file integrity plugin for those who prefer xfs.