Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Sync Errors - after re-assigning drive connections (please help)!

Featured Replies

I am using unRAID 4.3.3 - I recently purchaced Adaptec 1430SA PciEx4 4 port sata and now I re-configured my server to have my drives to alternate connect to Adaptec 1430SA and MB built-in SATA ports. All drive assignments is the same as old configuration.

 

NEW configuration:

Parity > Adaptec 1430SA

Disk1 > MB built-inSATA port

Disk2 > Adaptec 1430SA

 

NOTE: Old configuration - all Drives were using MB built-in SATA ports.

 

STEPS:

1. RUN Parity check (day before)

2. Unassign all drives

3. STOP array and then SHUTDOWN server

4. Install Adaptec 1430SA

5. Re-connect all drives to configuration above

6. Power up server

7. START the Array (without using RESTORE button)

 

Now I have 1058 errors detected in parity (progress is 25 % complete). Did I miss something or should I hit restore instead?

 

Thanks for the help!

 

 

 

DON'T HIT RESTORE.

 

Your existing data drives may be giving read errors.

 

I'd stop the parity check, and check the smart stats on all the drives, and see if they are having errors.

 

 

A parity check corrects parity errors as it goes.  So if a parity check is showing 1058 parity errors, there have been 1058 updates to the parity to "correct" those errors.  None of the data disks get updated in this process.

 

Is it possible that you rebooted without doing a clean shutdown?  That can cause symptoms like you are describing on a parity check.

 

I'd seek to verify that all of my data drive contents look correct.  If one of the data disks is acting strangely, I'd shut down and trying to figure out why.  Could be a lose cable or could be you need to assign that drive to another port or could be the drive is failing (pretty unlikely).  After all the disks look okay, I'd run up to 2 more parity checks looking for a clean run.  If you don't get a clean run after 2 consecuritve parity checks, you've got bigger problems to solve.

 

I'd suggest posing a syslog immediately.  It will contain details on the sectors that were updated on the parity disk.

 

  • Author

Thanks guys for the quick response - I stop parity check now going try smart stat and check for connections.

I also realized that my server reset the time and date to 12-31-2003 I am not sure if this causing errors but I really need to check everything.

 

Attached is my syslog.

 

Thanks!

 

  • Author

UPDATE:

I rebooted my server many times and my MB was not detecting Adaptec 1430SA which forced me to reset my BIOS. After BIOS was reseted everything seems to be working good - 55% complete on parity check still ne errors (finger crossed).  ;) I will run another parity check after this as bjp999 suggested to make sure.

 

@ bubbaQ & bjp999 Thanks for responding and validating my steps.

  • Author

Okay I spoke too soon - my MB only recognize Adaptec 1430SA if I reset my BIOS. Everytime I rebooted my server it won't see the Adaptec controller BUT then again if I reset my BIOS it will see it again.

 

Mother Board: MSI K8N NEO4-F V.1

 

Does it mean my MB is not compatible with it?

 

Thanks!

check for a bios uopdate...

 

I looked at your syslog posted below.  I am far from an expert in reading these, but did notice the following messages related to a parity check ...

Dec 31 16:46:00 tower kernel: md0: parity incorrect: 210936
Dec 31 16:46:03 tower kernel: md0: parity incorrect: 765496
Dec 31 16:46:04 tower kernel: md0: parity incorrect: 932336
Dec 31 16:46:05 tower kernel: md0: parity incorrect: 1149632
Dec 31 16:46:12 tower kernel: md0: parity incorrect: 2501096
Dec 31 16:46:14 tower kernel: md0: parity incorrect: 2760432
Dec 31 16:46:14 tower kernel: md0: parity incorrect: 2837544
Dec 31 16:46:14 tower kernel: md0: parity incorrect: 2890624
Dec 31 16:46:15 tower kernel: md0: parity incorrect: 2919576
Dec 31 16:46:15 tower kernel: md0: parity incorrect: 2942800
Dec 31 16:46:17 tower kernel: md0: parity incorrect: 3323672
Dec 31 16:46:21 tower kernel: md0: parity incorrect: 3982440
Dec 31 16:46:21 tower kernel: md0: parity incorrect: 3988832
Dec 31 16:46:21 tower kernel: md0: parity incorrect: 4024848

 

It looks like a short burst of parity errors at the beginning of the check.  I believe this is characteristic of a dirty shutdown.

 

I don't know what you mean by "RESET MY BIOS".  At first I thought you had loaded a BIOS update, but based on your last message am not sure. If you DID update your BIOS, make sure you go into the BIOS and reset your settings to default - and then make your BIOS mods.  New BIOSes can make use of CMOS memory differently and not doing that can cause very strange problems.

 

I also don't know why you think the MB is not recognizing the Adaptc 1430SA controller.  If you boot up unRAID and the array starts with drives that are connected to that controler - then the controller IS being recognized. If a controller is not being recognized, the drives themselves will not be there and the array will not start.

 

I think that the way parity works with unRAID is confusing.  Below is an example that I hope will help clear up some of the confusion ...

 

Suppost you buy a controller that has a firmware bug which results in returning bad data for 1000 specific sectors on connected disks.  (This would never happen).

 

1.  Parity is perfect before you install the new controller.

 

2.  You add the controler and move one DATA disk to the new controller.

 

3.  You then run the parity check.  The check will find 1000 parity errors, and for each one it will update the PARITY disk (not the DATA disk), assuming that all the data disks were perfect. 

 

4.  You run parity check again - no errors.

 

5.  You then read about a firmware update to fix a bad problem.  You shutdown unRAID, install the firmware update (that fixes the controller), and startup unRAID.

 

6.  You then run the parity check again.  It will find 1000 parity errors, and for each one it will update the PARITY disk, just like before.

 

7.  You run parity check again - no errors.

 

The state of the arry at step 4 is the confusing thing.  Although you get zero parity errors, the truth is one of your disks is returning bad data.  This means that if that data disk were to fail, and unRAID were to rebuild it, it would rebuild it with the 1000 data errors.  At step 7, the parity is correct, and if the disk were to fail you'd rebuild it correctly.

 

So in your prior post you said that you ran a parity check, it found 1058 bad sectors, and then you did something, and ran parity again and it found zero errors.  You seemed to think you fixed something.  The truth is that means whatever you did have NO effect.  If you had changed something it would have found 1058 parity errors and put things back to the way they started.  Make sense?

 

Again, I think the 1058 errors were likely related to a dirty shutdown and that you likely have nothing to worry about there.  If your controller is really not being recognized, THAT is a problem - but if that is the case, drives should be completely missing when you boot unRAID.

 

Hope this makes sense.

 

UPDATE:  I just looked again at the syslog and noticed that you actually cut out a bunch of your syslog.  You need to post the parity error portion to be able to make more sense of what may have gone wrong.

  • Author

MB BIOS is up to date.

 

BIOS RESET: as in turn OFF power and press reset button by 3V battery on my MB. (clear CMOS right?)

 

I did my parity check twice and pass 2 times last night... That's only because I watch my server boot and as soon as I saw that Adaptec 1430SA was not recognize by MB I don't let it boot to unRAID.

 

Suppost you buy a controller that has a firmware bug which results in returning bad data for 1000 specific sectors on connected disks.  (This would never happen).

 

1.  Parity is perfect before you install the new controller.

 

2.  You add the controler and move one DATA disk to the new controller.

 

3.  You then run the parity check.  The check will find 1000 parity errors, and for each one it will update the PARITY disk (not the DATA disk), assuming that all the data disks were perfect. 

 

4.  You run parity check again - no errors.

 

5.  You then read about a firmware update to fix a bad problem.  You shutdown unRAID, install the firmware update (that fixes the controller), and startup unRAID.

 

6.  You then run the parity check again.  It will find 1000 parity errors, and for each one it will update the PARITY disk, just like before.

 

7.  You run parity check again - no errors.

 

PARITY CHECK passes only if my MB recognize the controller.

 

NO FIRMWARE was updated during this process.

 

All I did was install the controller and re-assign connections. My MB seems to recognize controller only after BIOS reset. BUT then again if I reboot my server again 99% it will not recognize the controller and will go right away to boot to unRAID.

 

I am corncern right now is... Why my MB only recognize controller during fresh BIOS reset?

 

@ bjp999:

Thank you for looking at my syslog. Like what I mentioned parity passes 2 times now IF controller is detected by MB, I am assuming it's all well. Is it? I am actually thinking removing the 3V battery and see what it does.  :-\ Really desperate as I am lossing sleep...  ;D ;D

 

 

  • Author

To Validate my theory: I remove 3V battery and I rebooted it 5 times boot and detected my controller everytime. Now my question how do I fix this issue? For MB BIOS version (ver 1.D) is up to date and I don't think MSI releasing anymore update. My other option is to update firmware on ADaptec 1430SA to their latest one. I'll post back my result.

Try moving the controller to a different slot if possible.

There are also sometimes options in the bios referencing reserved bios space or bootable bios. 

Try altering those settings if they are available.

 

it seems as though the bios of the card is not being detected or it is being bypassed.

The 1430SA does have a BIOS setup screen.  I forget the exact settings I had to use to use it as a JBOD controller.

As for the 1430sa, if you never enter it's bios, it is jbod.  As for the reset thing, check your bios options for PCIe slot options, such as Force X1, etc....

The 1430SA does have a BIOS setup screen.  I forget the exact settings I had to use to use it as a JBOD controller.

 

I have 2 of the 1430SA's. I went into the Bios of the cards and disabled the Bios.

  • Author

I went few days with a little sleep.  :( :(

 

I did consider bjp999 said that my controller might have a bug of some kind... I did actually update the firmware and and I am getting a little better response from my cotroller, it actually boot 4-5 times with out hicups but then again it happen again and again without recognizing my card.

 

My resolution is to buy the same controller and see if I get the same problem.. It would be a smart or dumb choice but I would need 2 of the controllers in the future anyways. So I went ahead and put an order for a new one. I will update when I get the new one.

  • Author

UPDATE:

I recieved my new controller and so far its working without a problem.

 

I probably have to RMA my defective controller now.

 

Everyone thanks for the support.

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.