Marky Posted November 29, 2016 Share Posted November 29, 2016 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 Quote Link to comment
trurl Posted November 29, 2016 Share Posted November 29, 2016 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? Quote Link to comment
garycase Posted November 29, 2016 Share Posted November 29, 2016 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). Quote Link to comment
Marky Posted November 29, 2016 Author Share Posted November 29, 2016 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 Quote Link to comment
garycase Posted November 29, 2016 Share Posted November 29, 2016 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. Quote Link to comment
Marky Posted November 29, 2016 Author Share Posted November 29, 2016 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? Quote Link to comment
trurl Posted November 29, 2016 Share Posted November 29, 2016 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? Quote Link to comment
garycase Posted November 29, 2016 Share Posted November 29, 2016 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. Quote Link to comment
Marky Posted November 30, 2016 Author Share Posted November 30, 2016 I have no spare SATA ports so the unassigned devices plugin is not really an option. With both drives in a different box wether it be Windows or Linux the drives would be mounted read only for sure. Mark Quote Link to comment
garycase Posted November 30, 2016 Share Posted November 30, 2016 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. Quote Link to comment
Marky Posted November 30, 2016 Author Share Posted November 30, 2016 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 Quote Link to comment
garycase Posted November 30, 2016 Share Posted November 30, 2016 Linux Reader is actually very simple -- you can easily access the files from any Windows utility that uses an Explorer interface. Quote Link to comment
Marky Posted November 30, 2016 Author Share Posted November 30, 2016 Am I doing something wrong as I can't access anything from outside the Linux Reader interface. Also read online of a comparision of these mount utils and it also said you couldn't. Mark Quote Link to comment
Marky Posted November 30, 2016 Author Share Posted November 30, 2016 Have just found that there is a Linux Reader plugin for Total Commander. This will be perfect for me as the diff tool in TC is really good. Mark Quote Link to comment
Marky Posted December 23, 2016 Author Share Posted December 23, 2016 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 Quote Link to comment
Recommended Posts
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.