November 12, 20187 yr Currently running on 6.6.5 but this has been going on since the initial release of 6.6.x, it did not happen on the previous versions. I have my Parity check scheduled to run at 12:30am Sunday, once a week. Unfortunately it runs every single day. Typically takes about 10.5 hours so the server is pretty slow while it is running. Activity started on Mon 12 Nov 2018 12:30:01 AM MST (today), finding 0 errors. Last result: 10 hours, 39 minutes, 34 seconds. Average speed: 104.3 MB/s Sample from the parity-check.log 2018 Oct 19 10:40:08|38407|104.2 MB/s|0|0 2018 Oct 20 10:39:36|38375|104.3 MB/s|0|0 2018 Oct 21 10:41:08|38467|104.0 MB/s|0|0 2018 Oct 22 10:39:47|38386|104.2 MB/s|0|0 2018 Oct 23 08:40:18|31217|Unavailable|-4|0 2018 Oct 24 11:58:23|41302|96.9 MB/s|0|0 2018 Oct 25 11:13:32|38611|103.6 MB/s|0|0 2018 Nov 1 12:39:17|43756|91.4 MB/s|0|0 2018 Nov 2 12:48:33|44312|90.3 MB/s|0|0 2018 Nov 3 12:28:36|43115|92.8 MB/s|0|0 2018 Nov 4 11:00:43|41442|96.5 MB/s|0|0 2018 Nov 5 12:10:18|42017|95.2 MB/s|0|0 2018 Nov 6 12:07:48|41867|95.6 MB/s|0|0 2018 Nov 7 10:16:49|35208|Unavailable|-4|0 1969 Dec 31 17:00:00|0|nan B/s|| 2018 Nov 10 11:10:08|38407|104.2 MB/s|0|0 2018 Nov 11 11:09:35|38374|104.3 MB/s|0|0 The times you see gaps is when I have turned off the check in frustration, no idea what the Dec 31 one is all about. Current check (going on right now): Total size:4 TB Elapsed time:9 hours, 21 minutes Current position:3.59 TB (89.7 %) Estimated speed:92.5 MB/sec Estimated finish:1 hour, 14 minutes Sync errors corrected:0 Anyone have any ideas on what I can check in order to figure this out? It never says it has to write corrections, so I don't know if something hardware wise is causing it to kick off (you would think it would be telling me if that was the issue). I have attached the diagnostics, screenshot of the scheduler. If anything else is needed, I can upload that also. jupiter-diagnostics-20181112-0948.zip
November 12, 20187 yr 11 minutes ago, Startide said: Currently running on 6.6.5 but this has been going on since the initial release of 6.6.x, it did not happen on the previous versions. I have my Parity check scheduled to run at 12:30am Sunday, once a week. Unfortunately it runs every single day. Typically takes about 10.5 hours so the server is pretty slow while it is running. Activity started on Mon 12 Nov 2018 12:30:01 AM MST (today), finding 0 errors. Last result: 10 hours, 39 minutes, 34 seconds. Average speed: 104.3 MB/s Sample from the parity-check.log 2018 Oct 19 10:40:08|38407|104.2 MB/s|0|0 2018 Oct 20 10:39:36|38375|104.3 MB/s|0|0 2018 Oct 21 10:41:08|38467|104.0 MB/s|0|0 2018 Oct 22 10:39:47|38386|104.2 MB/s|0|0 2018 Oct 23 08:40:18|31217|Unavailable|-4|0 2018 Oct 24 11:58:23|41302|96.9 MB/s|0|0 2018 Oct 25 11:13:32|38611|103.6 MB/s|0|0 2018 Nov 1 12:39:17|43756|91.4 MB/s|0|0 2018 Nov 2 12:48:33|44312|90.3 MB/s|0|0 2018 Nov 3 12:28:36|43115|92.8 MB/s|0|0 2018 Nov 4 11:00:43|41442|96.5 MB/s|0|0 2018 Nov 5 12:10:18|42017|95.2 MB/s|0|0 2018 Nov 6 12:07:48|41867|95.6 MB/s|0|0 2018 Nov 7 10:16:49|35208|Unavailable|-4|0 1969 Dec 31 17:00:00|0|nan B/s|| 2018 Nov 10 11:10:08|38407|104.2 MB/s|0|0 2018 Nov 11 11:09:35|38374|104.3 MB/s|0|0 The times you see gaps is when I have turned off the check in frustration, no idea what the Dec 31 one is all about. Current check (going on right now): Total size:4 TB Elapsed time:9 hours, 21 minutes Current position:3.59 TB (89.7 %) Estimated speed:92.5 MB/sec Estimated finish:1 hour, 14 minutes Sync errors corrected:0 Anyone have any ideas on what I can check in order to figure this out? It never says it has to write corrections, so I don't know if something hardware wise is causing it to kick off (you would think it would be telling me if that was the issue). I have attached the diagnostics, screenshot of the scheduler. If anything else is needed, I can upload that also. jupiter-diagnostics-20181112-0948.zip Confirmed. Those settings result in a cron of # Generated parity check schedule: 30 0 * * * /usr/local/sbin/mdcmd check &> /dev/null || : For the time being you can run the check on any day other than sunday and it will work properly.
November 12, 20187 yr Author So I just happened to choose the one day that resulted in a bug? lol Just my luck. Didn't even think to check the actual crontab file. # Generated parity check schedule: 30 0 * * * /usr/local/sbin/mdcmd check &> /dev/null || : I changed it to Saturday and it is correct. # Generated parity check schedule: 30 0 * * 6 /usr/local/sbin/mdcmd check &> /dev/null || : So it should read (if I remember my cron entries): 30 0 * * 0 /usr/local/sbin/mdcmd check &> /dev/null || : 0 = Sunday, * = All Thank you for the sanity check.
Archived
This topic is now archived and is closed to further replies.