September 23, 20178 yr During rc8q I have 1st time booup then parity auto check itself, and yesterday upgrade rc9f same thing happen again. dmseg output, I stop it [ 169.872357] BTRFS info (device md1): disk space caching is enabled [ 169.872360] BTRFS info (device md1): has skinny extents [ 171.857217] BTRFS info (device md1): new size for /dev/md1 is 3000592928768 [ 172.351266] BTRFS info (device md2): disk space caching is enabled [ 172.351269] BTRFS info (device md2): has skinny extents [ 175.906543] BTRFS info (device md2): new size for /dev/md2 is 6001175072768 [ 176.459116] BTRFS info (device md3): disk space caching is enabled [ 176.459120] BTRFS info (device md3): has skinny extents [ 178.900819] BTRFS info (device md3): new size for /dev/md3 is 6001175072768 [ 179.383256] BTRFS info (device md4): disk space caching is enabled [ 179.383259] BTRFS info (device md4): has skinny extents [ 182.702808] BTRFS info (device md4): new size for /dev/md4 is 6001175072768 [ 183.014679] BTRFS info (device md5): disk space caching is enabled [ 183.014683] BTRFS info (device md5): has skinny extents [ 186.210745] BTRFS info (device md5): new size for /dev/md5 is 6001175072768 [ 186.548266] BTRFS info (device md6): disk space caching is enabled [ 186.548270] BTRFS info (device md6): has skinny extents [ 189.854173] BTRFS info (device md6): new size for /dev/md6 is 6001175072768 [ 190.240211] BTRFS info (device md7): disk space caching is enabled [ 190.240214] BTRFS info (device md7): has skinny extents [ 190.279987] BTRFS info (device md7): new size for /dev/md7 is 6001175072768 [ 190.306995] BTRFS info (device nvme0n1p1): disk space caching is enabled [ 190.306998] BTRFS info (device nvme0n1p1): has skinny extents [ 190.311457] BTRFS info (device nvme0n1p1): detected SSD devices, enabling SSD mode [ 190.921931] mdcmd (45): check nocorrect [ 190.921947] md: recovery thread: check P Q ... [ 190.927722] md: using 3072k window, over a total of 5860522532 blocks. [ 2501.583465] mdcmd (46): nocheck [ 2501.589507] md: md_do_sync: got signal, exit... [ 2501.602833] md: recovery thread: completion status: -4 Syslog Sep 23 11:04:17 X370 kernel: mdcmd (31): set md_num_stripes 2560 Sep 23 11:04:17 X370 kernel: mdcmd (32): set md_sync_window 768 Sep 23 11:04:17 X370 kernel: mdcmd (33): set md_sync_thresh 384 Sep 23 11:04:17 X370 kernel: mdcmd (34): set md_write_method 1 Sep 23 11:04:17 X370 kernel: mdcmd (35): set spinup_group 0 0 Sep 23 11:04:17 X370 kernel: mdcmd (36): set spinup_group 1 0 Sep 23 11:04:17 X370 kernel: mdcmd (37): set spinup_group 2 0 Sep 23 11:04:17 X370 kernel: mdcmd (38): set spinup_group 3 0 Sep 23 11:04:17 X370 kernel: mdcmd (39): set spinup_group 4 0 Sep 23 11:04:17 X370 kernel: mdcmd (40): set spinup_group 5 0 Sep 23 11:04:17 X370 kernel: mdcmd (41): set spinup_group 6 0 Sep 23 11:04:17 X370 kernel: mdcmd (42): set spinup_group 7 0 Sep 23 11:04:17 X370 kernel: mdcmd (43): set spinup_group 29 0 Sep 23 11:04:17 X370 kernel: mdcmd (44): start STOPPED Sep 23 11:04:39 X370 kernel: mdcmd (45): check nocorrect Sep 23 11:43:10 X370 kernel: mdcmd (46): nocheck Edited September 23, 20178 yr by Benson
September 23, 20178 yr If you want any informed feedback then you should post the diagnostics zip file (obtained via Tools->Diagnostics.
September 23, 20178 yr 5 minutes ago, realies said: Can confirm the same behaviour. helion-diagnostics-20170923-1933.zip Sep 23 08:05:23 Helion emhttpd: unclean shutdown detected I see the same thing occasionally in the 6.4 Series, where even on a clean shutdown for some reason the system thinks its unclean.
September 23, 20178 yr 6 minutes ago, Squid said: Sep 23 08:05:23 Helion emhttpd: unclean shutdown detected I see the same thing occasionally in the 6.4 Series, where even on a clean shutdown for some reason the system thinks its unclean. Could it be because of a Windows 10 VM that was running before the shutdown and was installing updates? Right before the system was shut down, the Windows 10 VM screen text went from something along the lines of "Configuring updates... 30%" to "Shutting down...". Could it be that because of the VM not being stopped prior the shutdown process, unRAID thinks it is unclean?
September 24, 20178 yr Author @Squid Thanks your info. I also found "unclean shutdown detected" in my system. But I think it is false detect. After 1st PQ auto check, I stop it and some days later perfortm a fully check and no any error report. My system was simple, no VM / docker, just a file server. It is headness and on demand power on/off by passing power-buttom. So all data disk usually in standby and will auto wakup in shutdown subroutine. From now on, I set "Shutdown time-out:" from 60 to 120, I hope this will solve my problem. I am a guy who quite concern the data integerity, all disk will manual check parity monthly, all file have hash mark by FIP and Checksum suite. In past time, all parity check also health with linear result. 2017-09-23, 11:43:10 38 min, 31 sec Unavailable Canceled 0 2017-09-22, 21:22:33 11 hr, 27 min, 44 sec 145.4 MB/s OK 0 2017-09-03, 20:02:43 11 hr, 31 min, 9 sec 144.7 MB/s OK 0 2017-08-01, 07:49:40 11 hr, 27 min, 39 sec 145.5 MB/s OK 0 2017-06-26, 05:18:18 11 hr, 28 min, 49 sec 145.2 MB/s OK 0 2017-06-24, 12:25:55 9 hr, 38 min, 7 sec 173.0 MB/s OK 0 2017-06-10, 05:19:42 11 hr, 25 min, 11 sec 146.0 MB/s OK 0 2017-05-27, 23:03:20 11 hr, 29 min, 37 sec 145.0 MB/s OK 0 2017-05-04, 08:57:12 11 hr, 22 min, 41 sec 146.5 MB/s OK 0 2017-04-15, 12:19:37 11 hr, 29 min, 4 sec 145.2 MB/s OK 0 2017-03-18, 09:42:01 11 hr, 30 min, 9 sec 144.9 MB/s OK 0 2017-03-16, 16:54:26 11 hr, 27 min, 56 sec 145.4 MB/s OK 0 2017-03-10, 04:16:12 11 hr, 23 min, 33 sec 146.3 MB/s OK 0 2017-02-22, 03:50:33 11 hr, 44 min, 50 sec 141.9 MB/s OK 0 2017-01-22, 04:54:10 11 hr, 48 min, 58 sec 141.1 MB/s OK 0 2016-12-29, 05:33:44 11 hr, 46 min, 12 sec 141.6 MB/s OK 0 2016-12-03, 11:16:04 11 hr, 49 min, 7 sec 141.0 MB/s OK 0 2016-11-26, 09:35:50 11 hr, 41 min, 51 sec 142.5 MB/s OK 0 2016-11-25, 21:09:59 11 hr, 44 min, 2 sec 142.1 MB/s OK 0 2016-11-22, 23:57:35 11 hr, 26 min, 20 sec 145.7 MB/s OK 0 2016-11-18, 22:58:47 11 hr, 46 min, 39 sec 141.5 MB/s OK 0 2016-11-01, 22:39:11 11 hr, 47 min, 41 sec 141.3 MB/s OK 0 2016-10-14, 07:36:05 11 hr, 46 min, 55 sec 141.5 MB/s OK 0 2016-09-09, 00:04:55 11 hr, 37 min, 1 sec 143.5 MB/s OK 0 2016-08-20, 13:13:30 11 hr, 42 min, 56 sec 142.3 MB/s OK 0 2016-08-19, 09:31:43 10 hr, 25 min, 14 sec 160.0 MB/s OK 0 2016-08-18, 22:58:35 10 hr, 28 min, 29 sec 159.1 MB/s OK 0 2016-08-02, 20:48:09 10 hr, 14 min, 8 sec 162.9 MB/s OK 0 2016-08-02, 05:28:07 10 hr, 22 min, 24 sec 160.7 MB/s OK 0 2016-07-22, 23:53:22 10 hr, 31 min, 4 sec 158.5 MB/s OK 0 2016-07-14, 13:43:27 11 hr, 40 min, 46 sec 142.7 MB/s OK 0 2016-07-03, 12:05:27 10 hr, 39 min, 43 sec 156.3 MB/s OK 0 2016-06-25, 13:30:49 11 hr, 21 min, 21 sec 146.8 MB/s OK 0 2016-06-14, 05:40:54 10 hr, 39 min, 8 sec 156.5 MB/s OK 0 2016-06-10, 19:23:53 10 hr, 43 min, 47 sec 155.4 MB/s OK 0 2016-05-20, 22:20:25 14 hr, 23 min, 1 sec 115.9 MB/s OK 0 2016-04-20, 10:22:45 14 hr, 16 min, 4 sec 116.8 MB/s OK 0 Edited September 24, 20178 yr by Benson
October 9, 20178 yr Is there a resolution to this? I have upgraded to 6.4 and every single time I perform a reboot the server claims the last shutdown was unclean. I have increased the shutdown timeout to 120 seconds but am still experiencing the issue.
October 9, 20178 yr 3 hours ago, Enver said: Is there a resolution to this? I have upgraded to 6.4 and every single time I perform a reboot the server claims the last shutdown was unclean. I have increased the shutdown timeout to 120 seconds but am still experiencing the issue. Have you tried stopping the array and then only when it is successfully stopped shutting down/rebooting the server? If the array will not successfully stop then you need to look into what is causing that to happen. If you have topped the array successfully and you still get a parity check on reboot then this would suggest that there is some sort of problem with the USB stick that is preventing unRAID from updating it to say that stopping the array was successful.
October 24, 20178 yr On 10/10/2017 at 12:26 AM, itimpi said: Have you tried stopping the array and then only when it is successfully stopped shutting down/rebooting the server? If the array will not successfully stop then you need to look into what is causing that to happen. If you have topped the array successfully and you still get a parity check on reboot then this would suggest that there is some sort of problem with the USB stick that is preventing unRAID from updating it to say that stopping the array was successful. Array fails to stop manually through the GUI. It seems the array is waiting for the LibVirt.img file on the cache pool and never exits. Any ideas?
October 24, 20178 yr 19 minutes ago, Enver said: It seems the array is waiting for the LibVirt.img file on the cache pool and never exits. Any ideas? Any running VM?
Archived
This topic is now archived and is closed to further replies.