I am seeing this on my main page after a reboot.

 

Isn't it support to remember this across reboots?

As far as I know, it remembers the time of the last parity check, but not the duration ... which is stored in the log, which, as you know, is not persistent.

 

There was a post in the feature request sub-forum for this.

 

http://lime-technology.com/forum/index.php?topic=36545.0

 

I think it is a great idea myself. It is probably trivial to add but maybe not for 6.0.

 

There are some other good ones in there too and I forget to put my 2 cents in to support the ideas that I think are good ones.

 

Gary

It would also be nice if a parity check history was maintained so that you could see the times for more than just the last one.

It would also be nice if a parity check history was maintained so that you could see the times for more than just the last one.

 

Yes, it would be. I actually maintain an Excel spreadsheet for this and sometimes I forget to update it.

It would also be nice if a parity check history was maintained so that you could see the times for more than just the last one.

 

Excellent suggestion.

 

Now I think part of the reason this wasn't done before is by design to reduce wear and tear on the flash drive. However this seems worth it, and also pretty infrequent.

I have a method I'm testing out .

 

I have a parity_check crontable in /etc/cron.d as follows

root@unRAID:/boot/local/etc/cron.d# more parity_check 
00 00 27 * * /root/mdcmd check NOCORRECT
35 04 * * * test ! -d /boot/log && mkdir -p /boot/log
36 04 * * * egrep 'md: sync' /var/log/syslog | fgrep -v -f /boot/log/syslog.mdsync  >> /boot/log/syslog.mdsync
#
# * * * * * <command to be executed>
# | | | | |
# | | | | |
# | | | | +---- Day of the Week   (range: 1-7, 1 standing for Monday)
# | | | +------ Month of the Year (range: 1-12)
# | | +-------- Day of the Month  (range: 1-31)
# | +---------- Hour              (range: 0-23)
# +------------ Minute            (range: 0-59)

 

 

In a few days I'll add some logic to restore the last parity check back to the syslog file if there is no 'md: sync' string.

I'm debating on the addition via cronjob or via hook in the post rotate block in /etc/logrotate.d/syslog

It would be pretty much be a tail -1 from /boot/log/syslog.mdsync onto /var/log/syslog 'if' it's rotated.

Probably would be better to have emhttp/dynamix look in an alternate location of history if not found, rather then appending back to syslog.

Probably would be better to have emhttp/dynamix look in an alternate location of history if not found, rather then appending back to syslog.

I would agree with this.  I think the history would be better served from a separate file on the flash drive.  I run parity checks infrequently - once per month - once I'm setup so the boot flash should survive that.  If this was going to be updated more frequently - say once a week - I would suggest it go to the catch drive - but once a month should be safe for the flash drive.  Just wish I had more sd card reader's and then once a week or more frequently wouldn't be a problem either.

Perhaps put this as a feature request.

 

Ideally I would see this as the system (emhttp) write a log message to flash upon termination of a parity operation. A function can be built into the GUI to show the log messages in a presentable way.