JazzHands

Sync does not block for hours while other processes are writing to disk. It flushes all pending writes and doesn't wait around for any writes that may come in the future. root@Storage:~# ps u | grep preclear; time sync root 13161 0.7 0.0 10560 6548 pts/0 S+ 11:45 0:00 /bin/bash /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/preclear_disk.sh --cycles 1 --no-prompt /dev/sdj root 13190 0.0 0.0 8812 2216 pts/0 S+ 11:45 0:00 /bin/bash /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/preclear_disk.sh --cycles 1 --no-prompt /dev/sdj root 15661 0.0 0.0 10632 5416 pts/0 S+ 11:45 0:00 /bin/bash /usr/local/emhttp/plugins/unassigned.devices.preclear/scripts/preclear_disk.sh --cycles 1 --no-prompt /dev/sdj root 23684 0.0 0.0 4052 2200 pts/1 S+ 11:46 0:00 grep preclear real 0m0.004s user 0m0.002s sys 0m0.002s Here's me running a sync while a preclear is running. The sync completes in milliseconds. EDIT: OF course I'd need to run it during the write stage. Yep, sync blocks. Interesting, TIL.

I have an issue that a preclear on one disk not yet added to array is preventing the format of a newly added disk. Formatting of a newly added disk normally takes a few minutes, but when running a preclear the format does not complete at all. The solution is to pause or stop any preclear jobs running, then format completes almost immediately. I have two disks I want to add to my array. I started pre-clearing both. One (sdb) finished a few hours before the other (sdc). I stopped my array. The sdc preclear is automatically paused. Adding sdb to the Array then start it up. The preclear on sdc automatically resumes. Unraid prompts me to format sdb, which I do. The format will not complete while a preclear on another disk is running. Pausing the clear will allow the format to complete within a minute. Not a major issue for me as there is a workaround, just annoying. storage-diagnostics-20240814-1932.zip

Plex doesn't fully support Arc yet for hardware transcoding, although there is work being done on this. If all your clients can display and want to receive 4K video then you don't need to do any transcoding at all. If you do need to do some transcoding, then get yourself a Raptor Lake Intel CPU. Their transcoding performance is far better than you'd think, and they'll do so more efficiently than any GPU. I have a 10th gen i3 (i3-10100) on the server that I run Emby on and it can do 2 or 3 real time 4K transcodes. An 13th gen i7 can do a dozen or two.

I have a lead on a well priced Supermicro 6047R chassis and pretty much all the hardware except hard drives (dual E5-2609 v2, a couple SFP and 10GBe cards, AOC-S3008L-L8E, SAS3, X9DRD-EF). It's in good nick and has all caddies intact. My plans are to keep it quite simple for long term archiving and backup to populate it with a variety of cheaper disks with good quality parity disks and standbys. It'll run a few apps, nothing too taxing. I have a little concern about the reliability of such old hardware. Replacing the backplane alone is double the cost of the chassis. As is the motherboard, although dual socket is a bit overkill. All the other components can be easily replaced at a decent price. I'm a bit concerned about having a hot noisy power drain. Is it a white elephant using old hardware or would I be buying a stalwart?

I didn't want all disks to be actively read concurrently. Spinning up all disks at the same time some times initiates a shutdown. Reading from all disks concurrently initiates a shutdown. Testing each disk individually or in pairs is fine. A Rebuild and Parity Check were causing a shutdown. In the last day I also haven't been able to start the server with all disks powered. The only way I could was to power half, get to BIOS and power up the remaining one at a time. I've replaced the PSU and a Rebuild has started successfully. It seems to have been solved.

Yeah, although I've never known a bad drive to cause an immediate power shutdown. I'm trying a badblocks concurrently on all HDDS - to test everything in between and that just triggered a shutdown. I'll do a long test on them all concurrently. If it is a power related issue that should trigger it. If it's my controller or something in between, they should all pass. I'll try a badblocks on each individually afterwards. PSU is a 450W Gold desktop PSU. My calculated peak power consumption is 390W. PSU is 2.5 years old and been running constantly all this time, so it might be giving up on life. The PSU is on an inverter with a true sine output.

short test passed on all disks. One (sdc) took longer than the others to complete. Nothing specific is jumping out a bit. smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.49-Unraid] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red (SMR) Device Model: WDC WD60EFAX-68JH4N1 Serial Number: WD-WX82DA169313 LU WWN Device Id: 5 0014ee 214defcc3 Firmware Version: 83.00A83 User Capacity: 6,001,175,126,016 bytes [6.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Form Factor: 3.5 inches TRIM Command: Available, deterministic, zeroed Device is: In smartctl database 7.3/5533 ATA Version is: ACS-3 T13/2161-D revision 5 SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sun Oct 15 19:03:15 2023 SAST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (14504) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 730) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x3039) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 218 218 021 Pre-fail Always - 4083 4 Start_Stop_Count 0x0032 097 097 000 Old_age Always - 3214 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6206 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 258 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 21 193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 5187 194 Temperature_Celsius 0x0022 113 109 000 Old_age Always - 37 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 6206 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.

Of course it will, I'm not thinking straight today. In the meantime I'm doing smartctl tests on all disks.

I've been experiencing some random shutdowns in the last few days. Starting up the machine is difficult, almost as if there isn't enough power to power up all devices, but the PSU should have more than enough capacity (6 HDDs, 2 SSDs, Quaddro K620, GB NIC, 16GB DDR4). One HDD is a parity, the SSDs are in their own cache pools. I can only reliably startup when about half my disks are powered, and I power the rest one by one before bootup. With all of them connected, I can start up only about 10% of the time. I made the assumption that it was power related (it still might be), and managed to boot up successfully. While I had the server open, I used the opportunity to swap out a disk for increased capacity, however starting the array now that triggers a rebuild results in the system powering down immediately. I managed to catch some logs: Oct 15 17:37:58 Tower kernel: ata3.00: exception Emask 0x10 SAct 0x400 SErr 0x4890000 action 0xe frozen Oct 15 17:37:58 Tower kernel: ata3.00: irq_stat 0x08400040, interface fatal error, connection status changed Oct 15 17:37:58 Tower kernel: ata3: SError: { PHYRdyChg 10B8B LinkSeq DevExch } Oct 15 17:37:58 Tower kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata3.00: cmd 61/40:50:80:15:00/05:00:00:00:00/40 tag 10 ncq dma 688128 out Oct 15 17:37:58 Tower kernel: res 40/00:50:80:15:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata3.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata3: hard resetting link Oct 15 17:37:58 Tower kernel: ata2.00: exception Emask 0x10 SAct 0x207f8 SErr 0x4090000 action 0xe frozen Oct 15 17:37:58 Tower kernel: ata2.00: irq_stat 0x00400040, connection status changed Oct 15 17:37:58 Tower kernel: ata2: SError: { PHYRdyChg 10B8B DevExch } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/38:18:90:35:00/00:00:00:00:00/40 tag 3 ncq dma 28672 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/38:20:c8:35:00/05:00:00:00:00/40 tag 4 ncq dma 684032 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/08:28:00:3b:00/04:00:00:00:00/40 tag 5 ncq dma 528384 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/38:30:08:3f:00/01:00:00:00:00/40 tag 6 ncq dma 159744 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/c0:38:40:40:00/02:00:00:00:00/40 tag 7 ncq dma 360448 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/08:40:00:43:00/00:00:00:00:00/40 tag 8 ncq dma 4096 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/c8:48:08:43:00/02:00:00:00:00/40 tag 9 ncq dma 364544 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/40:50:d0:45:00/05:00:00:00:00/40 tag 10 ncq dma 688128 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:37:58 Tower kernel: ata2.00: cmd 60/40:88:c0:1a:00/05:00:00:00:00/40 tag 17 ncq dma 688128 in Oct 15 17:37:58 Tower kernel: res 40/00:50:d0:45:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 17:37:58 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:37:58 Tower kernel: ata2: hard resetting link And on another startup: Oct 15 17:56:17 Tower kernel: ata4.00: exception Emask 0x50 SAct 0x400000 SErr 0x4090800 action 0xe frozen Oct 15 17:56:17 Tower kernel: ata4.00: irq_stat 0x00400040, connection status changed Oct 15 17:56:17 Tower kernel: ata4: SError: { HostInt PHYRdyChg 10B8B DevExch } Oct 15 17:56:17 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata4.00: cmd 60/d0:b0:80:58:00/02:00:00:00:00/40 tag 22 ncq dma 368640 in Oct 15 17:56:17 Tower kernel: res 40/00:b0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata4.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata4: hard resetting link Oct 15 17:56:17 Tower kernel: ata3.00: exception Emask 0x50 SAct 0x3000 SErr 0x4890800 action 0xe frozen Oct 15 17:56:17 Tower kernel: ata3.00: irq_stat 0x08400040, interface fatal error, connection status changed Oct 15 17:56:17 Tower kernel: ata3: SError: { HostInt PHYRdyChg 10B8B LinkSeq DevExch } Oct 15 17:56:17 Tower kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata3.00: cmd 61/40:60:d0:45:00/05:00:00:00:00/40 tag 12 ncq dma 688128 out Oct 15 17:56:17 Tower kernel: res 40/00:68:10:4b:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata3.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata3.00: cmd 61/38:68:10:4b:00/00:00:00:00:00/40 tag 13 ncq dma 28672 out Oct 15 17:56:17 Tower kernel: res 40/00:68:10:4b:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata3.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata3: hard resetting link Oct 15 17:56:17 Tower kernel: ata2.00: exception Emask 0x50 SAct 0x1e8060 SErr 0x4090800 action 0xe frozen Oct 15 17:56:17 Tower kernel: ata2.00: irq_stat 0x00400040, connection status changed Oct 15 17:56:17 Tower kernel: ata2: SError: { HostInt PHYRdyChg 10B8B DevExch } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/40:28:80:15:00/05:00:00:00:00/40 tag 5 ncq dma 688128 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/40:30:c0:1a:00/05:00:00:00:00/40 tag 6 ncq dma 688128 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/38:78:48:4b:00/05:00:00:00:00/40 tag 15 ncq dma 684032 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/08:88:80:50:00/04:00:00:00:00/40 tag 17 ncq dma 528384 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/38:90:88:54:00/01:00:00:00:00/40 tag 18 ncq dma 159744 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/c0:98:c0:55:00/02:00:00:00:00/40 tag 19 ncq dma 360448 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 17:56:17 Tower kernel: ata2.00: cmd 60/d0:a0:80:58:00/02:00:00:00:00/40 tag 20 ncq dma 368640 in Oct 15 17:56:17 Tower kernel: res 40/00:a0:80:58:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 17:56:17 Tower kernel: ata2.00: status: { DRDY } Oct 15 17:56:17 Tower kernel: ata2: hard resetting link and again: Oct 15 18:13:54 Tower kernel: r8169 0000:02:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM Oct 15 18:13:55 Tower kernel: ata4.00: exception Emask 0x10 SAct 0x1cc000 SErr 0x4090000 action 0xe frozen Oct 15 18:13:55 Tower kernel: ata4.00: irq_stat 0x00400040, connection status changed Oct 15 18:13:55 Tower kernel: ata4: SError: { PHYRdyChg 10B8B DevExch } Oct 15 18:13:55 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata4.00: cmd 60/38:70:c8:35:00/05:00:00:00:00/40 tag 14 ncq dma 684032 in Oct 15 18:13:55 Tower kernel: res 40/00:a0:00:43:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata4.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata4.00: cmd 60/08:78:00:3b:00/04:00:00:00:00/40 tag 15 ncq dma 528384 in Oct 15 18:13:55 Tower kernel: res 40/00:a0:00:43:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata4.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata4.00: cmd 60/38:90:08:3f:00/01:00:00:00:00/40 tag 18 ncq dma 159744 in Oct 15 18:13:55 Tower kernel: res 40/00:a0:00:43:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata4.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata4.00: cmd 60/c0:98:40:40:00/02:00:00:00:00/40 tag 19 ncq dma 360448 in Oct 15 18:13:55 Tower kernel: res 40/00:a0:00:43:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata4.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata4.00: cmd 60/d0:a0:00:43:00/02:00:00:00:00/40 tag 20 ncq dma 368640 in Oct 15 18:13:55 Tower kernel: res 40/00:a0:00:43:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata4.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata4: hard resetting link Oct 15 18:13:55 Tower kernel: ata2.00: exception Emask 0x50 SAct 0x3ec0 SErr 0x4090800 action 0xe frozen Oct 15 18:13:55 Tower kernel: ata2.00: irq_stat 0x00400040, connection status changed Oct 15 18:13:55 Tower kernel: ata2: SError: { HostInt PHYRdyChg 10B8B DevExch } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/40:30:80:15:00/05:00:00:00:00/40 tag 6 ncq dma 688128 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/40:38:c0:1a:00/05:00:00:00:00/40 tag 7 ncq dma 688128 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/38:48:c8:35:00/05:00:00:00:00/40 tag 9 ncq dma 684032 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/08:50:00:3b:00/04:00:00:00:00/40 tag 10 ncq dma 528384 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/38:58:08:3f:00/01:00:00:00:00/40 tag 11 ncq dma 159744 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/c0:60:40:40:00/02:00:00:00:00/40 tag 12 ncq dma 360448 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2.00: failed command: READ FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata2.00: cmd 60/d0:68:00:43:00/02:00:00:00:00/40 tag 13 ncq dma 368640 in Oct 15 18:13:55 Tower kernel: res 40/00:68:00:43:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata2.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata2: hard resetting link Oct 15 18:13:55 Tower kernel: ata3.00: exception Emask 0x50 SAct 0xc0 SErr 0x4090800 action 0xe frozen Oct 15 18:13:55 Tower kernel: ata3.00: irq_stat 0x00400040, connection status changed Oct 15 18:13:55 Tower kernel: ata3: SError: { HostInt PHYRdyChg 10B8B DevExch } Oct 15 18:13:55 Tower kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata3.00: cmd 61/40:30:50:30:00/05:00:00:00:00/40 tag 6 ncq dma 688128 out Oct 15 18:13:55 Tower kernel: res 40/00:38:90:35:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata3.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata3.00: failed command: WRITE FPDMA QUEUED Oct 15 18:13:55 Tower kernel: ata3.00: cmd 61/38:38:90:35:00/00:00:00:00:00/40 tag 7 ncq dma 28672 out Oct 15 18:13:55 Tower kernel: res 40/00:38:90:35:00/00:00:00:00:00/40 Emask 0x50 (ATA bus error) Oct 15 18:13:55 Tower kernel: ata3.00: status: { DRDY } Oct 15 18:13:55 Tower kernel: ata3: hard resetting link Any idea what could be going on here? I am able to remove the new disk and put in the old, but Unraid refuses to accept the new disk into the array because it is 2TB and the new is 6TB. The array does start, but in degraded mode with one disk missing. Would creating a new config trigger a rebuild?

Do you know if there is a notification if an array isn't auto-started? I have all notifications enabled, but don't recall seeing any.

This is working. The only downside is that when power is restored, the array needs to be manually started. Started about 2200 last night, had a power outage at 0200-0430. Array wasn't started automatically. Manually starting it caused the rebuild to resume. 5 hours to go, not counting another 2 hour outage.

Power cuts happen on average every 8-12 hours and have been for 6 months (South Africa). My UPS only provides about 40 minutes of runtime during a parity check, so I assume it's about the same when rebuilding. I'll have to make a plan to find a window long enough for a rebuild.

Sorry, I didn't understand, is that a yes?

It may sound like a bit of an oxymoronic question, but I'd like to swap out an older drive with a new higher capacity one in my single parity disk protected array. Rebuild will take about 16 hours, but it will be interrupted with a power outage. Server has a UPS and shuts down gracefully. Will a graceful shut down and start up cause a rebuild to restart from the beginning? Or can it resume?