chris1259 Posted May 16, 2018 Share Posted May 16, 2018 OS v6.5.1 Notice [SERVER] - Parity check finished (9 errors) Where is the location of the log that shows what the errors are? I don't see any errors listed under Tools/System Log. The MAIN tab shows that no device has errors and all SMART tests show "Completed without error". Thanks. Quote Link to comment
JorgeB Posted May 16, 2018 Share Posted May 16, 2018 The sync errors are logged on the syslog, but it's not possible to know from which disk(s) they came from and/or affected files. Quote Link to comment
chris1259 Posted May 16, 2018 Author Share Posted May 16, 2018 Well that is disappointing. Thanks for responding. Quote Link to comment
JorgeB Posted May 16, 2018 Share Posted May 16, 2018 If there was an unclean shutdown since the last check a few sync errors are expected, if not there's likely some hardware problem, like bad RAM, board, etc, in normal usage the only number of acceptable sync errors is 0. Quote Link to comment
chris1259 Posted May 16, 2018 Author Share Posted May 16, 2018 Thanks for the updated info. There was a unclean shutdown in the last week or so due to a loss of power. The parity check that finished today now shows zero errors. So it's very possible that was culprit. Quote Link to comment
pwm Posted May 16, 2018 Share Posted May 16, 2018 5 hours ago, chris1259 said: Thanks for the updated info. There was a unclean shutdown in the last week or so due to a loss of power. The parity check that finished today now shows zero errors. So it's very possible that was culprit. Without disk controller cards with battery backup to cache writes until the individual disks have reported back an acknowledge, it's practically impossible to get multi-disk updates (such as data+parity updates) to correctly synchronize to all involved disks unless the updates are first performed to a separate single-device commit log. It's normally not a problem that you get a number of errors when synchronizing the parity after an unclear shutdown. Each individual data disk has a file system with some form of journaling, or similar intended to limit the danger to the individual file systems. The content of the individual data disks might roll back in time a number of seconds to a state where at least the meta data (allocation tables, directory trees etc) are in a stable state. Files currently open for write might suffer from broken content - or if the file was new might be totally removed. It's basically these kinds of pending changes to the individual data disks that the parity drives will not always correctly capture - so you get a few parity errors representing the parity blocks that got recomputed to match the final data disk content. 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.