ReLe

Just an update, after moving to LSI9207, from LSI2008 on 3.11.2022, no errors after switch to this date. But, who knows what it really was in my case and when the Ironwolf disks start to act again.

Quite interesting thread. Came here trough Google when searching what to do in my situation. I thought that it would be possible somehow do this or at least maybe it would be implemented. I have to migrate my unraid to mATX case when we move for 2 months to escape apartment water pipes renovation. I can't take the array disks with me (power consumption and there is no room for large tower) but I need to run the vm's. Currently thinking of moving mobo (small B660 with 12100) and only vm ssd + os ssd to small case and install proxmox to run the vm's. After I move back I probably will run Unraid as vm in proxmox with nic&hba passthrough, going forward to get around the vm debacle. I have had my fights with array before, having to run repairs etc to disks and I can't have the downtime for the vm's during those periods.

I'm having the same issue. Started happening last saturday 26.11. Noticed this on the log from last night. 2022-11-28 04:27:40 information: skip_vm_shutdown is false. beginning vm shutdown procedure. 2022-11-28 04:27:40 information: xxxyyyy is shut off. vm desired state is shut off. can_backup_vm set to y. 2022-11-28 04:27:40 information: actually_copy_files is 1. 2022-11-28 04:27:40 information: can_backup_vm flag is y. starting backup of xxxyyyy configuration, nvram, and vdisk(s). 2022-11-28 04:27:40 information: copy of xxxyyyy.xml to /mnt/user/backup/xxxyyyy/20221128_0400_xxxyyyy.xml complete. 2022-11-28 04:27:40 information: copy of /etc/libvirt/qemu/nvram/XXXXX_VARS-pure-efi.fd to /mnt/use r/backup/xxxyyyy/20221128_0400_XXXXX_VARS-pure-efi.fd complete. 2022-11-28 04:50:14 information: copy of /mnt/disks/XXXXXDISK/domains/Ubuntu/vdisk1.img to /mnt/user/backup/xxxyyyy/20221128_ 0400_vdisk1.img complete. 2022-11-28 04:50:15 information: backup of /mnt/disks/XXXXXDISK/domains/Ubuntu/vdisk1.img vdisk to /mnt/user/backup/xxxyyyy/2 0221128_0400_vdisk1.img complete. 2022-11-28 04:50:15 information: extension for /mnt/cache/gparted-live-1.1.0-1-i686.iso on xxxyyyy was found in vdisks_extensions_ to_skip. skipping disk. 2022-11-28 04:50:15 information: the extensions of the vdisks that were backed up are img. 2022-11-28 04:50:15 information: vm_state is shut off. vm_original_state is shut off. not starting xxxyyyy. 2022-11-28 04:50:15 information: backup of xxxyyyy to /mnt/user/backup/xxxyyyy completed. So apparently somehow the script fails to write the on/off state prior backing up, since it states "vm_state is shut off. vm_original_state is shut off. not starting xxxyyyy." Other vm's get properly booted up. EDIT: Works again after rebooting

My latest fails were on H310 crossflash LSI 2008 based card and Unraid version 6.11.1. On 3.11.2022 switched to LSI9207 and time will tell if this helps.

Thanks for the reply. Just to rule out possible issues with the controller, I just ordered a refurbished 9207 (server pull from reputable seller) and will see if problems will get resolved.

Again had issues with my iron wolf drives. Have disabled low power spin with seachest (epc is not found on my drives feature list). Eventually I'm going to move to WD red plus drives, but in meantime I was wondering that is this issue with all LSI controllers. Would it help if I would switch from H310 2008 based controller to 9207-8i? I have the latest FW on my current LSI.

Thanks @optiman I tried with the 2019 version got same error as before. EPC feature is not listed with info command. I tested the drive with (Asus Deluxe X79) motherboard integraded ?marvell? sata controller and also intel sata ports and neither controller paired with the Seagate disk lists EPC in info. Info: SeaChest_Info_150_11923_64 -d /dev/sg4 -i ========================================================================================== SeaChest_Info - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2019 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_Info Version: 1.5.0-1_19_23 X86_64 Build Date: Jun 10 2019 Today: Fri Dec 10 20:13:30 2021 ========================================================================================== /dev/sg4 - ST4000VN008-2DR166 - xxxxxxxx - ATA Model Number: ST4000VN008-2DR166 Serial Number: xxxxxxxxxx Firmware Revision: SC60 World Wide Name: 5000C500C97E2CB5 Drive Capacity (TB/TiB): 4.00/3.64 Native Drive Capacity (TB/TiB): 4.00/3.64 Temperature Data: Current Temperature (C): 28 Highest Temperature (C): 41 Lowest Temperature (C): 0 Power On Time: 85 days 23 hours 43 minutes Power On Hours: 2063.72 MaxLBA: 7814037167 Native MaxLBA: 7814037167 Logical Sector Size (B): 512 Physical Sector Size (B): 4096 Sector Alignment: 0 Rotation Rate (RPM): 5980 Form Factor: 3.5" Last DST information: DST has never been run Long Drive Self Test Time: 10 hours 9 minutes Interface speed: Max Speed (Gb/s): 6.0 Negotiated Speed (Gb/s): 3.0 Annualized Workload Rate (TB/yr): 123.25 Total Bytes Read (TB): 20.87 Total Bytes Written (TB): 8.17 Encryption Support: Not Supported Cache Size (MiB): 64.00 Read Look-Ahead: Enabled Write Cache: Enabled Low Current Spinup: Disabled SMART Status: Good ATA Security Information: Supported Firmware Download Support: Full, Segmented, Deferred, DMA Specifications Supported: ACS-3 ACS-2 ATA8-ACS ATA/ATAPI-7 ATA/ATAPI-6 ATA/ATAPI-5 ATA/ATAPI-4 SATA 3.1 SATA 3.0 SATA 2.6 SATA 2.5 SATA II: Extensions SATA 1.0a ATA8-AST Features Supported: Sanitize SATA NCQ SATA Rebuild Assist SATA Software Settings Preservation [Enabled] SATA Device Initiated Power Management HPA Power Management Security SMART [Enabled] DCO 48bit Address PUIS APM [Enabled] GPL Streaming SMART Self-Test SMART Error Logging Write-Read-Verify Sense Data Reporting [Enabled] SCT Write Same SCT Error Recovery Control SCT Feature Control SCT Data Tables Host Logging Seagate In Drive Diagnostics (IDD) However, I noticed that when I run the info, I get following errors to dmesg: ata5.00: invalid command format 2 Every Seagate disk queryed with the seachest_info gives that error to dmesg from their ata address.

Tried the EPC disabling when one of my relatively new Seagate Iron wolf drives got disabled in Unraid 6.9.2 and LSI controller, detailed info below Num Ctlr FW Ver NVDATA x86-BIOS PCI Addr ---------------------------------------------------------------------------- 0 SAS2008(B2) 20.00.07.00 14.01.00.08 No Image 00:03:00:00 SeaChest_PowerControl_x86_64-redhat-linux --scan --onlySeagate ATA /dev/sg11 ST4000VN008-2DR166 SC60 SeaChest_PowerControl_x86_64-redhat-linux -d /dev/sg11 --EPCfeature disable ========================================================================================== SeaChest_PowerControl - Seagate drive utilities - NVMe Enabled Copyright (c) 2014-2021 Seagate Technology LLC and/or its Affiliates, All Rights Reserved SeaChest_PowerControl Version: 3.0.2-2_2_3 X86_64 Build Date: Jun 17 2021 Today: Fri Dec 10 01:53:39 2021 User: root ========================================================================================== /dev/sg11 - ST4000VN008-2DR166 - ZDH9N576 - ATA Failed to send EPC command to /dev/sg11. EPC Feature set might not be supported. Or EPC Feature might already be in the desired state. Did I miss something? I dont see EPC in info listing and I am unable to set EPC. Is this because drive is connected to LSI controller?

Thanks, I fetched those log files, but did not see anything alarming and did not have time (two kids under 4 running and screaming around my server) to clean up them from my personal data. I noticed that my old AMD C60 8W CPU was running 100% all the time. It worked ok in previous builds tho... So I made upgrade with 80€, 40€ for Intel G1820 and 40€ for ASROCK H81-VG4. I threw in Intel 9301ct Gigabit NIC and 4 port SATA3 card totalling 8 ports, to supply my 6 drives. Now I get 795Mbps write and 891Mbps read to cache drive. So it was probably the CPU bottlenecking system, or infamous realtek RT8111 or both. Old system consumed 68W when doing partity check. Now new system pulls 76W, but now my processor is 7x faster and paritycheck speed is running 40-130MB/s and when i access my share, filelisting is instant. This was not the case in my older builds.

Immediately after upgrading to V6 write speeds to my 7400k 640GB HDD cachedrive were 60-70MB/s. My cache drive stays almost empty most of the time, with daily writings at 2-32GB. Suddently the write speed dropped to 28MB/s. Cables from 1000M router to workstation and undraid are 1m long CAT6. Network speed is negotiated at 1000M. Parity check runs at 50-80MB/s range without errors, so disks should be ok.

...And if the image of the chipset used is correct it is build around Broadcom http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM5356x-Family chip that has 10/100 integrated switch.

From what i tried to decode from the Korean brochure, my understanding is as follows. LAN 100M, WAN upto 165M, WLAN 300M. But since the most informative parts are images, it's not possible to verify by google translate. http://www.iptime.co.kr/~iptime/prd.php?pf=3&page=&pt=129&pd=1

Server was not booted cleanly, that's why the parity check started in first place. I have to fetch UPS back from basement to prevent the unplanned shutdowns. I just swapped parity drive to new WD RED 3TB and sync is going on at 35-70MB/s, so looks like the slowness was caused by the parity disc WD Green. I will mark this as solved once parity sync is complete.

After reboot, server started parity check and it is progressing very very slowly. I have also noticed that playing music from share gets interrupted every 2minutes also when parity check is not in progress. After this issue occured, I updated from 5.0 to 5.05 and updated bios to see if that has any effect and it did not. I also opened case, disconnected all sata cables and plugged them back. In syslog there is nothing that would point to disk failures. Smart data from all discs is fine, no pending sector writes or anything i could use to get the discs replaced under warranty. I have parity + 5 discs. Where to start? Total size: 3 TB Current position: 190.9 MB (0%) Estimated speed: 116.85 KB/sec Estimated finish: 425449 minutes Parity disc is WD Caviar Green. One of my friends said he had problems with green drives in linux. Is this the problem. It worked fine until now. Edit: Tried to find culprit by testing write speed with command hdparm -tT /dev/hda on each drive. Executing this command hangs forever. It does not matter what drive i try to test. Edit 2: Actually after around 20minutes i got one line from parity drive: Timing buffered disk reads: 2 MB in 80.40 seconds = 25.47 kB/sec I still haven't got test results from another drives. If they also display kB/sec readings, then it's tricky. If only parity drive is in kB range, it will be sent to WD for replacement Edit 3: Readouts from other drives: /dev/sdb: Timing buffered disk reads: 590 MB in 3.00 seconds = 196.51 MB/sec /dev/sde: Timing buffered disk reads: 230 MB in 3.01 seconds = 76.35 MB/sec /dev/sdc: Timing buffered disk reads: 428 MB in 3.01 seconds = 142.33 MB/sec /dev/sdd: Timing buffered disk reads: 310 MB in 3.01 seconds = 103.06 MB/sec /dev/hdb: Timing buffered disk reads: 2 MB in 6.47 seconds = 316.31 kB/sec This is interesting. hdb is also WD green red and seems like we have issue here. Either both of them are broken or i have wrong setting somewhere set for these drives. System used to work before though. Edit 4: Switched from IDE satamode to ACHI. It was set to IDE because with version 4 and previous BIOS i would get around 5-10MB/s partiy check instead of 70-100. After this parity drive is still slow, but test with the RED drive show (dev name changed beacuse of SATA mode): /dev/sdg: Timing buffered disk reads: 460 MB in 3.01 seconds = 152. Also if i access file that is on that drive i get around 50-70MB/s rate in Windows. So all in all it now seems that parity drive will be sent for RMA, after i get parity check done, I will see if the RED drive needs replacement as well. I also remenber seeing ERRORS listed for the parity drive at some point. I will update here what happened once i get the drive swapped. Final update: After changing parity drive with new one, server is now again running well two parity checks passed with 35-100MB/s speed. It seemed like the IDE mode put the two 3TB drives in same channel so that when parity slowed down, that slowed the second, healthy drive as well. Now also web GUI is fast again. syslog_unraid.txt