v5 Sync errors after data disk upgrade


Recommended Posts

After some advice on the best way to procede. Here is what I did.

 

1) Ran a parity check, all fine no errors.

2) Upgraded data disk to a larger one and rebuilt data.

3) Ran a non-correcting check to make sure everything was good, 5 sync errors.

 

No errors showing in the ui on any disk so I'm wondering what caused these. Never had it happen before.

 

Would it be best to do another data rebuild and run the parity check again?

 

Also thinking of connecting the old and new disk to another box and running a binary diff on the files to check them.

 

Any advice would be appreciated.

 

Mark

 

 

Link to comment

It's possible the rebuild had a small glitch, but more than likely these are legitimate parity errors.

 

I'd just run a correcting check to fix parity -- then re-run it to confirm all is well -- and then, if you want to do a sanity check on all your files, just attach the old drive using the Unattached devices plugin, and run a binary comparison on the files [You could also attach the old drive to a client PC and do the comparison across the network, as long as the client can read the file system on the disk (XFS or Reiser).

 

 

Link to comment

5 parity errors after a data disk rebuild would seem to imply that the rebuilt data doesn't match parity. I would say rebuild again except for these 2 questions:

 

Did you preclear or otherwise test the new disk?

 

What about SMART for all drives?

 

I did run a full preclear on the new disk, all clear.

SMART checks on all drives are good.

 

It was my assumption that the rebuild had a glitch as parity would not be written to on a rebuild unless there were errors.

No errors shown on UI after the rebuild on any disk.

 

First time I have seen this happen and upraded many disks in the same system over the years.

 

Mark

 

Link to comment

Won't hurt to just do the rebuild again, just to be sure.

 

Note, however, that if the errors are indeed on the parity disk, this will result in an incorrect rebuild, with no indication of that.

 

The only way to be CERTAIN in your case is a binary comparison of the old and new disks.

 

This is a key reason why I always suggest maintaining checksums of all of your files -- it's then very easy to confirm whether a file is good or not.

 

 

Link to comment

 

Hard to know the exact cause I guess. Parity was good before the rebuild. No read errors shown on any disk after rebuild.

They only showed after a non-correcting check after the rebuild was complete.

Parity should only be read during rebuild so not sure how there would be parity errors.

 

I think my plan to be safe is to put old and new disks in a different box and binary diff the files.

If all files match then I guess there are parity errors so I can do a correcting parity.

 

If they don't match then a do another rebuild, check parity and then also binary diff again.

 

Anything wrong with this plan?

 

 

Link to comment

 

Hard to know the exact cause I guess. Parity was good before the rebuild. No read errors shown on any disk after rebuild.

They only showed after a non-correcting check after the rebuild was complete.

Parity should only be read during rebuild so not sure how there would be parity errors.

 

I think my plan to be safe is to put old and new disks in a different box and binary diff the files.

If all files match then I guess there are parity errors so I can do a correcting parity.

 

If they don't match then a do another rebuild, check parity and then also binary diff again.

 

Anything wrong with this plan?

Without more details about exactly how you intend to put the drives in a different box I would say don't do it. If another operating system does anything to your drives you will invalidate parity. Why can't you do the compare with them in the same box using Unassigned Devices?
Link to comment

I don't think it matters which box you use for the comparison as long as you don't do ANY writes to the disks.  I agree, however, that as long as you've got a spare SATA port it seems most convenient to just use Unassigned Devices to attach the old drive and then you can simply do the comparison in the server.

 

Link to comment

Does the drive use Reiser or XFS?

 

You could leave the new drive in the system (as it is right now), and mount the old drive in a PC, and then just do the comparison across your network.  You'd need an installable file system to read the Linux files -- but that's not a problem.

 

For Reiser you can use Linux Reader:  https://www.diskinternals.com/linux-reader/

 

I'm not aware of any XFS readers for Windows.  What I know some folks have done is use a Linux VM running on Windows to access an XFS disk; and shared that disk as R/O on their local network -- so Windows can access it.    Then you could use a Windows utility to compare the files on that disk with those on your UnRAID server.

 

Or perhaps somebody else can chime in with a link to an XFS file system reader.

 

Another option, if you have enough free space on a drive in your PC, would be to mount the disk in your PC;  boot to a "Live CD" version of Linux (e.g. Knoppix); and just copy the files from the XFS disk to the disk on your PC.    Then you could easily do the comparison directly from the copies on the Windows machine.

 

Link to comment

Its Reiser.

 

I've just been looking at Linux reader, unfortunately it does not look like you can use any external tools. No driver letter or mount point externally.

 

I'm thinking of the network route, safest to leave the new drive where it is.

 

Easier I think to just mount the old drive in a Linux install read only.

 

Any recommend utility on Linux to do the full directory compare of all files?

 

Thanks for your help.

 

Mark

 

Link to comment
  • 4 weeks later...

So wanted to give an update on this as it is strange.

 

I compared all the files and only one file was different, so replaced the bad file on the new disk.

Ran a correcting parity check to fix anything.

Did a non correcting check to make sure and no sync errors.

 

Here's where it gets strange.

 

I've upgraded another disk and the same thing happened.

Re-built fine, no errors.

Did a non correcting check and again 5 sync errors.

Compared all the files and again only one file is different.

 

This time I had a look at the contents of the bad file. There was a whole section of zero's

but in part of that block was the string EFI PART.

 

This seems odd to me as though wrong data was written on the rebuild.

Wonder if I'm hitting an edge case somehow of a bug?

 

Before I update any more drives I'm going to move to V6 I think.

 

Mark

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.