February 6, 20251 yr I have been running a parity for about 10 days now (not sure how to check the full length because when it pauses and restarts it resets the page timer). The first 30% or so ran normal as far as I could tell (50-100MB/s, took about 1.5 days which makes sense as my normal parity runs take 4-7 days). It has been at 500KB/s-1MB/s since then. I am assuming I have a bad disk issue, however my DiskSpeed results are all where I expect them to be, maybe slightly slower... but nothing lower that 35MB/s)... nothing 600KB/s close. Any help would be much appreciated. This is the first parity I have run under unRAID 7 (don't think thats the issue but wanted to note it just in case). This is a 2 parity (14TB each), 18 drive array, all ZFS. 185TB of 210TB used. My last successful parity run was 4-5 days on 12/25/24 and averaged 35MB/s. Logs attached. Finally, I know those read/write numbers are pretty abysmal in general and would love to know if that just is what it is or if I can look into making that better at all? I guess I never really cared since it has 0 impact on Plex which is all its used for. hades-diagnostics-20250206-1745.zip
February 6, 20251 yr Community Expert It looks like you have writing going on to many of your disks in parallel to the parity check. While this is happening both the check and the writing will be badly affected.
February 6, 20251 yr Author 5 minutes ago, itimpi said: It looks like you have writing going on to many of your disks in parallel to the parity check. While this is happening both the check and the writing will be badly affected. writing from what? My parity runs mainly from 1am until 5pm so I should get excellent speeds from 1am-10am when Plex isnt in use no? Nothing else should be burning up the writing.
February 6, 20251 yr Author fyi, these are my 4 drives with SMART Errors... Only Disk 3 actually ever reported errors on the main page but I have been monitoring all these drives in case its beyond just a bad connection on the cable/power failure etc etc. DISK 1 (INTERNAL BAY) ATA Error Count: 4 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 4 occurred at disk power-on lifetime: 5817 hours (242 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 a8 f8 df 40 00 2d+16:13:46.938 READ FPDMA QUEUED 60 00 00 a8 f4 df 40 00 2d+16:13:43.839 READ FPDMA QUEUED 2f 00 01 10 00 00 00 00 2d+16:13:43.838 READ LOG EXT 2f 00 01 10 00 00 00 00 2d+16:13:43.838 READ LOG EXT 60 00 00 a8 f0 df 40 00 2d+16:13:40.917 READ FPDMA QUEUED Error 3 occurred at disk power-on lifetime: 5817 hours (242 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 a8 f0 df 40 00 2d+16:13:43.838 READ FPDMA QUEUED 60 00 00 a8 ec df 40 00 2d+16:13:40.916 READ FPDMA QUEUED 60 f8 00 b0 e9 df 40 00 2d+16:13:40.906 READ FPDMA QUEUED 60 08 00 a8 e8 df 40 00 2d+16:13:40.906 READ FPDMA QUEUED 60 00 00 a8 e4 df 40 00 2d+16:13:40.902 READ FPDMA QUEUED Error 2 occurred at disk power-on lifetime: 4166 hours (173 days + 14 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 90 f7 df 40 00 3d+23:08:22.399 READ FPDMA QUEUED 60 00 00 90 f3 df 40 00 3d+23:08:19.332 READ FPDMA QUEUED 2f 00 01 10 00 00 00 00 3d+23:08:19.332 READ LOG EXT 2f 00 01 10 00 00 00 00 3d+23:08:19.332 READ LOG EXT 60 00 00 90 ef df 40 00 3d+23:08:16.585 READ FPDMA QUEUED Error 1 occurred at disk power-on lifetime: 4166 hours (173 days + 14 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 90 ef df 40 00 3d+23:08:19.332 READ FPDMA QUEUED 60 00 00 90 eb df 40 00 3d+23:08:16.574 READ FPDMA QUEUED 60 00 00 90 e7 df 40 00 3d+23:08:16.570 READ FPDMA QUEUED 60 00 00 90 e3 df 40 00 3d+23:08:16.566 READ FPDMA QUEUED 60 00 00 90 df df 40 00 3d+23:08:16.561 READ FPDMA QUEUED DISK 3 (FRONT BAY) ATA Error Count: 3 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 3 occurred at disk power-on lifetime: 23994 hours (999 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 41 00 00 00 00 00 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 61 80 08 80 10 02 40 00 30d+11:40:19.568 WRITE FPDMA QUEUED 61 80 10 00 11 02 40 00 30d+11:40:19.567 WRITE FPDMA QUEUED 61 80 00 00 10 02 40 00 30d+11:40:19.566 WRITE FPDMA QUEUED 61 80 00 80 0f 02 40 00 30d+11:40:19.565 WRITE FPDMA QUEUED 61 80 08 00 78 f1 40 00 30d+11:40:19.561 WRITE FPDMA QUEUED Error 2 occurred at disk power-on lifetime: 13182 hours (549 days + 6 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 41 00 00 00 00 00 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 61 80 08 00 13 7f 40 00 27d+09:28:58.029 WRITE FPDMA QUEUED 61 80 38 00 fa 7e 40 00 27d+09:28:58.028 WRITE FPDMA QUEUED 61 80 30 80 fd 7e 40 00 27d+09:28:58.027 WRITE FPDMA QUEUED 61 80 28 80 13 7f 40 00 27d+09:28:58.027 WRITE FPDMA QUEUED 61 80 20 80 12 7f 40 00 27d+09:28:58.027 WRITE FPDMA QUEUED Error 1 occurred at disk power-on lifetime: 4352 hours (181 days + 8 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 41 00 00 00 00 00 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 61 00 18 d0 aa cf 40 00 42d+03:40:30.866 WRITE FPDMA QUEUED 61 00 10 d0 a8 cf 40 00 42d+03:40:30.851 WRITE FPDMA QUEUED 61 00 08 d0 a6 cf 40 00 42d+03:40:30.851 WRITE FPDMA QUEUED 61 00 00 d0 a4 cf 40 00 42d+03:40:30.851 WRITE FPDMA QUEUED 61 08 38 58 b7 df 40 00 42d+03:40:30.850 WRITE FPDMA QUEUED DISK 12 (FAN BAY) ATA Error Count: 4 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 4 occurred at disk power-on lifetime: 9633 hours (401 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 f8 af 20 40 00 17:13:06.322 READ FPDMA QUEUED 60 08 00 f0 af 20 40 00 17:13:03.484 READ FPDMA QUEUED 60 00 00 f0 ab 20 40 00 17:13:03.480 READ FPDMA QUEUED 60 00 00 f0 a7 20 40 00 17:13:03.476 READ FPDMA QUEUED 60 f8 00 f8 a3 20 40 00 17:13:03.472 READ FPDMA QUEUED Error 3 occurred at disk power-on lifetime: 9633 hours (401 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 f0 6b 20 40 00 17:13:03.147 READ FPDMA QUEUED 60 00 00 f0 67 20 40 00 17:13:00.240 READ FPDMA QUEUED 60 00 00 f0 63 20 40 00 17:12:58.043 READ FPDMA QUEUED 60 00 00 f0 5f 20 40 00 17:12:58.039 READ FPDMA QUEUED 60 00 00 f0 5b 20 40 00 17:12:58.035 READ FPDMA QUEUED Error 2 occurred at disk power-on lifetime: 9633 hours (401 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 f8 37 20 40 00 17:12:57.939 READ FPDMA QUEUED 60 00 00 f8 33 20 40 00 17:12:55.096 READ FPDMA QUEUED 60 00 00 f8 2f 20 40 00 17:12:55.092 READ FPDMA QUEUED 60 00 00 f8 2b 20 40 00 17:12:55.088 READ FPDMA QUEUED 60 00 00 f8 27 20 40 00 17:12:55.079 READ FPDMA QUEUED Error 1 occurred at disk power-on lifetime: 9633 hours (401 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 41 00 00 00 00 00 Error: UNC at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 00 f0 0b 20 40 00 17:12:54.997 READ FPDMA QUEUED 60 00 00 f0 07 20 40 00 17:12:52.144 READ FPDMA QUEUED 60 00 00 f0 03 20 40 00 17:12:52.141 READ FPDMA QUEUED 60 00 00 f0 ff 1f 40 00 17:12:52.137 READ FPDMA QUEUED 60 00 00 f0 fb 1f 40 00 17:12:52.131 READ FPDMA QUEUED DISK 15 (EXTERNAL BAY) ATA Error Count: 73 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 73 occurred at disk power-on lifetime: 4049 hours (168 days + 17 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 53 70 47 57 14 40 Error: ICRC, ABRT 112 sectors at LBA = 0x00145747 = 1333063 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 40 78 56 14 e0 08 19d+14:10:47.052 WRITE DMA EXT 35 00 40 38 51 14 e0 08 19d+14:10:47.048 WRITE DMA EXT 25 00 08 c0 e6 68 e0 08 19d+14:10:47.048 READ DMA EXT 25 00 08 c8 97 1a e0 08 19d+14:10:47.032 READ DMA EXT 35 00 40 f8 4b 14 e0 08 19d+14:10:47.031 WRITE DMA EXT Error 72 occurred at disk power-on lifetime: 4049 hours (168 days + 17 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 53 c1 66 d0 9f 40 Error: ICRC, ABRT 193 sectors at LBA = 0x009fd066 = 10473574 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 40 e8 cc 9f e0 08 19d+14:10:36.760 WRITE DMA EXT 35 00 40 a8 c7 9f e0 08 19d+14:10:36.737 WRITE DMA EXT 35 00 40 68 c2 9f e0 08 19d+14:10:36.736 WRITE DMA EXT 35 00 40 28 bd 9f e0 08 19d+14:10:36.734 WRITE DMA EXT 35 00 40 e8 b7 9f e0 08 19d+14:10:36.733 WRITE DMA EXT Error 71 occurred at disk power-on lifetime: 4049 hours (168 days + 17 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 53 b1 fe c0 93 40 Error: ICRC, ABRT 177 sectors at LBA = 0x0093c0fe = 9683198 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 40 70 bf 93 e0 08 19d+14:10:25.846 WRITE DMA EXT 35 00 40 30 ba 93 e0 08 19d+14:10:25.834 WRITE DMA EXT 25 00 08 70 71 40 e0 08 19d+14:10:25.834 READ DMA EXT 35 00 40 f0 b4 93 e0 08 19d+14:10:25.833 WRITE DMA EXT 35 00 40 b0 af 93 e0 08 19d+14:10:25.805 WRITE DMA EXT Error 70 occurred at disk power-on lifetime: 4049 hours (168 days + 17 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 53 f1 66 64 97 40 Error: ICRC, ABRT 241 sectors at LBA = 0x00976466 = 9921638 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 40 18 63 97 e0 08 19d+14:09:29.972 WRITE DMA EXT 35 00 40 d8 5d 97 e0 08 19d+14:09:29.957 WRITE DMA EXT 35 00 40 98 58 97 e0 08 19d+14:09:29.951 WRITE DMA EXT 35 00 40 58 53 97 e0 08 19d+14:09:29.943 WRITE DMA EXT 35 00 40 18 4e 97 e0 08 19d+14:09:29.937 WRITE DMA EXT Error 69 occurred at disk power-on lifetime: 4006 hours (166 days + 22 hours) When the command that caused the error occurred, the device was doing SMART Offline or Self-test. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 53 30 d7 73 84 40 Error: ICRC, ABRT 48 sectors at LBA = 0x008473d7 = 8680407 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 35 00 40 c8 72 84 e0 08 17d+19:44:14.664 WRITE DMA EXT 25 00 08 78 bf b0 e0 08 17d+19:44:14.661 READ DMA EXT 25 00 08 70 c0 b0 e0 08 17d+19:44:14.660 READ DMA EXT 25 00 08 70 bf b0 e0 08 17d+19:44:14.660 READ DMA EXT 35 00 40 88 6d 84 e0 08 17d+19:44:14.656 WRITE DMA EXT
February 6, 20251 yr Author DISREGARD, I mean, definitely see if I am messing something up but I realized manual parity checks were set to no and this was a manual one since I cancelled the scheduled one when I noticed the issue initially and needed to reboot the system. also, one more thing... am I using Parity Check Tuning wrong? I just noticed its still running despite being after my time was up... Shouldnt it have paused at 4pm, its 6:15pm ET now) Edited February 6, 20251 yr by wickedathletes I am a dolt and missed a setting
February 6, 20251 yr Author 25 minutes ago, itimpi said: It looks like you have writing going on to many of your disks in parallel to the parity check. While this is happening both the check and the writing will be badly affected. not sure if there is a better way to tell but I don't see anything
February 7, 20251 yr Community Expert According to that screenshot there is something reading from multiple disks
February 7, 20251 yr Community Expert 10 hours ago, wickedathletes said: also, one more thing... am I using Parity Check Tuning wrong? I just noticed its still running despite being after my time was up... Shouldnt it have paused at 4pm, its 6:15pm ET now) Your screenshot for the parity Tuning settings shows you are not using increments for Manual checks.
February 7, 20251 yr Author 5 hours ago, JorgeB said: According to that screenshot there is something reading from multiple disks Sorry, I was referring to the writes.
February 7, 20251 yr Author 3 hours ago, itimpi said: Your screenshot for the parity Tuning settings shows you are not using increments for Manual checks. Yes, I noticed that and adjusted. I shut down all dockers this AM and the best I’m getting is 3MB/s. any other guesses on what could be writing/reading from my disks? Also, why would it run at 30-40MB/s for the first 30-40% then immediately fall apart for the rest of the time? If it was a read/write activity it would be consistent based on activity no? My server activity is roughly the same daily.
February 7, 20251 yr Community Expert 1 hour ago, wickedathletes said: Sorry, I was referring to the writes. Any array reads will also slow down the parity check.
February 7, 20251 yr Author 34 minutes ago, JorgeB said: Any array reads will also slow down the parity check. any best guess on what is the best thing I can look into that is causing this? The first 30-40% run at 30-40MB/s. Then it crawls to 600KB/s. I shutdown all dockers and the best I can get it to is 5MB/s. This is reproducible and have little fluctuation depending on time of day (which to me means this isn't a read/write issue its something else. Nothing has changed since my last parity run besides all drives now being ZFS (I believe I had a few that still weren't in december) and unraid 7.0 full version (was on beta in dec.). My usage patterns haven't changed in years beyond maybe some more friends in plex (but currently Plex is off anyways).
February 7, 20251 yr Community Expert 51 minutes ago, wickedathletes said: The first 30-40% run at 30-40MB/s. And this was the normal speed? Start a parity check in maintenance mode and let it run for a few minutes, to confirm nothing is really assessing the array, if it's still slow, run the diskspeed docker tests.
February 7, 20251 yr Author 4 hours ago, JorgeB said: And this was the normal speed? Start a parity check in maintenance mode and let it run for a few minutes, to confirm nothing is really assessing the array, if it's still slow, run the diskspeed docker tests. diskspeed docker gives me 35-85 MB/s depending on the drive, I ran that a few days ago, with and without the parity being run, so oddly enough parity process had no impact to the diskspeed performance test. After shutting down all my dockers I am up to about 5-7MB/s and re-enabling them a few hours ago didn't impact that change, but something is still drawing 20+ MB/s from my typical times. And, as mentioned the first 40% or so runs at normal speed and then it crashes. This was seen 3 times in a row. At this point I don't want to restart it again though as at least now i am in a 20 days until finish window and its been running for over 10 days now. I would assume I would see the same thing again (for a 4th time) if I checked it. This parity to me is important because I have 2 drives I have been trying to add to the system to replace older ones but I want to make sure all is well before I do it, and I have major concerns that if a parity check is taking this long I can't have a data rebuild take 40 days... Also, one of the reasons I don't think its read/write is because I just kicked off a data transfer to my PC (200GB) and I am getting 40MB/s and parity check didnt change at all, still 5-7MB/s. Something else is happening I just don't know what. If parity is running and draining my server that bad then shouldn't everything be getting crushed to those speeds too? Edited February 7, 20251 yr by wickedathletes
February 8, 20251 yr Community Expert 11 hours ago, wickedathletes said: And, as mentioned the first 40% or so runs at normal speed and then it crashes That could mean a disk or more with slow sectors, diskspeed test sometimes shows this, but not always, since only a small percentage of the disk surface is tested, would still like to see the graphs, since the speeds you mentioned seem very low for modern disks.
February 8, 20251 yr Author 11 hours ago, JorgeB said: That could mean a disk or more with slow sectors, diskspeed test sometimes shows this, but not always, since only a small percentage of the disk surface is tested, would still like to see the graphs, since the speeds you mentioned seem very low for modern disks. Attached is from when I ran it a day or so ago. Also, I am back down to 700KB/s again. killing dockers 2 nights ago got it up to 7MB/s and restoring the dockers it stayed at 7MB/s but today its been 700KB/s all day.
February 9, 20251 yr Community Expert Well, there's definitely some issue, only two disks are performing normally, all the other ones are super slow, was the test done with the array running or stopped?
February 9, 20251 yr Author 8 hours ago, JorgeB said: Well, there's definitely some issue, only two disks are performing normally, all the other ones are super slow, was the test done with the array running or stopped? these results are with the array running (and they produce the same with parity paused or running). I know something is wrong, just dont know what or how to even diagnose what is happening. Everything is functioning as it normally does minus parity running like trash. My recent logs attached. hades-diagnostics-20250209-1433.zip Edited February 9, 20251 yr by wickedathletes
February 10, 20251 yr Community Expert Boot in in safe mode, disable docker and VM services, and see if you still see disk reads.
February 10, 20251 yr Author 7 hours ago, JorgeB said: Boot in in safe mode, disable docker and VM services, and see if you still see disk reads. So running a parity under safe mode has me at about 190 MB/s (its early, sub 1%). I will assume this will be the case until about 40% and then I will hit the same snag area. If not, maybe im good? But when I did it over the last few tries this month 0-40% was roughly 35MB/s (my normal, again with docker and everything running, not in safe mode) and then it haults for no real reason that I can see. Will monitor. Edited February 10, 20251 yr by wickedathletes
February 10, 20251 yr Author Is it common to see the speeds go down over time? 7hrs in (27%) and down to 96MB/s. until about 15% it maintained the 180-190MB/s.
February 10, 20251 yr Community Expert 1 minute ago, wickedathletes said: Is it common to see the speeds go down over time? 7hrs in (27%) and down to 96MB/s. until about 15% it maintained the 180-190MB/s. Yes. Access speeds of HDD drives decrease as you go from access the first sector to the very last. For my 16TB drives, that is nearly a 50% decrease. Parity speeds track with the speed of the drive with the slowest access speed.
February 14, 20251 yr Author On 2/10/2025 at 2:58 AM, JorgeB said: Boot in in safe mode, disable docker and VM services, and see if you still see disk reads. so running in safe mode had it finish with an average speed of 131MB/s. I noticed my cpu performance was pegged and I disabled folder cache plugin. This solved my processor issues, wondering if that was causing everything? The odd thing is this only started happening since 7.0 release. It worked as it normally did back on the RC's (I run parity every few months). No folder structures of cache folder settings changed, so not sure. I will see how it does with the array running soon (I have a scheduled on in 2 weeks).
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.