-
Notifications
You must be signed in to change notification settings - Fork 5
Duration and exit code of last parity check in $var #181
Comments
To review, here's how it works now:
So right, this is not so precise because it does not record whether the last parity check completed or not. Here are the actions that will cause a parity check/sync or data rebuild to abort:
Note that a parity operation is not cancelled as a result of "too many errors". Instead, the first 100 sync errors are logged in the system log. The 101'st sync error generates a log message that simply says " stopped logging", but the operation keeps marching along, incrementing 'sbSyncErrs'. As you know we are working on integrating P+Q array protection. Here's what I'll be adding to stored config data:
I'll probably be able to get above into 4.1 release (though P+Q will probably not be in 4.1 release). |
sbUpdated already gives the start time of the operation. I use it to show the "Elapsed time" when a parity operation is running. Can something like sbDuration be added to store the duration of the last parity check (or parity operation) ? |
sbUpdated gets updated every time there's an update, for example every Start array. |
At the moment I scan the syslog file to find duration and exit code of the last parity check, which is subsequently displayed on the Array Operation page, this is an inefficient approach - specially when the syslog file is big.
A better solution would be that duration and exit code are stored in $var. In conjunction with variable 'sbSynced'. These values can then be read instantly like all other values.
Bonus question: what parity check exit codes exist ?
The text was updated successfully, but these errors were encountered: