Jump to content
chris1259

Parity check error log location

6 posts in this topic Last Reply

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now