teakmeister

This was my thought too, will send the device back, thank you for your input.

I've popped the Kingston SSD into another unraid device (as the original one is busy pre-clearing a bunch of disks) using the onboard SATA ports and seeing the same oddities with the SMART count. I've copied some files to it and polled the SMART info during the copies: root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131325 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131318 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131318 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131316 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131316 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131315 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131315 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 196852 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 196852 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 196852 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 196852 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131316 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131316 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131316 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131315 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131315 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131315 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131310 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131310 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131310 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131309 root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 131309 Now correct me if I'm wrong, I didn't think that the CRC errors logged in SMART actually went down, unlike some of the other values which can if the issue is corrected. Value 2 mins after the last copy (my mind boggles...): root@Tucana:~# smartctl -a /dev/sdf | grep "199 SATA" | awk '{print $10}' 196845

Thank you JorgeB. Good point, the one thing I didn't try yesterday as the only free ports are SATA-2 on the motherboard, I'll shuffle a few drives round and give it a re-test. Since yesterday I've had the SSD in a USB3 caddy and the CRC errors have been jumping around there too... not convienced of the drive, but will re-test in the unraid server. Values whilst in the caddy (RAW and decimal): 40104 - 262,404 @ 16:59 30104 - 196,868 @ 18:50 20104 - 131,332 @ 22:17 40104 - 262,404 @ 10:00 50104 - 327,940 @ 11:20

Thank you bmartino1 for the info, my cache disk is a standard 2.5" SATA3 SSD, rather than NVMe, do you still think the above would be relevant?

Hi all, In the last week I managed to successfully swap out my old cache disk with a new Kingston SA400S37 (960GB) drive connected to a 6 port ASM1166 PCIe card (port 1). Today I plugged in an old 2TB disk in preparation to pre-clear/check it. In doing so the SSD needed to be unplugged (both power and data) and then re-plugged in. After booting Unraid, I was alerted to SMART errors on the SSD, and sure enough the drive was showing 100,000+ 199 SATA CRC error count (which is referred to 199 UDMA CRC error count for all other drives in the system). Understanding that this SMART metric tends to point to phsycial cabling issues, I shut the array down and checked/re-seated the cable at the SDD and controller end and powered back on. After a few minutes I was seeing the CRC values steadily increase. At this point I decided to swap out the SATA cable for a known good one, however the problem still persisted. Next I tried another port on the ASM1166 card (port 2) with another new cable, same issue. I have now run through the cache replacement procedure and put the original cache disk back in using the original port 1 on the ASM1166 card and the original SATA cable and re-tested... the old cache drive has no UDMA CRC error counts! So my question - is this new SSD bad, or is there some compatibility issues between the SSD and ASM1166 chipset? I've attached diagnostics, however the 'faulty' SSD is no longer in the array. Sample output from checking the SMART values when copying data to the Kingston SSD: Linux 6.1.79-Unraid. root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 262395 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196859 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196859 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196859 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131322 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131322 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131320 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131318 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131318 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131318 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 131318 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196858 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196858 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196858 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196858 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196858 root@Pyxis:~# smartctl -a /dev/sdg | grep "199 SATA" | awk '{print $10}' 196859 pyxis-diagnostics-20241202-1407.zip

Awesome, thank you for confirming, appreciate your input.

Thanks JorgeB, just did a bit of reading up on the CRC Error count, and you're on the money, I'll be swapping the motherboard out shortly so will swap out the cable to the drive also. In the past 8 weeks it's only increased by 2 so nothing major. I've also checked the other drives and the remainder have only a max of 2 values recorded. Perhaps I was a little quick to panic 😁

Although booting the array and checking the CRC count, it's increased by only 2 in the last 8 weeks, so will probably leave as is, but would be good to check my understanding on the procedure.

Hi all, I've got a 5 disk system with a parity disk that's slowly picking increasing UDMA CRC error count in SMART. The current disk config is: 3TB Parity 3TB Data 3TB Data 2TB Data 240GB Cache I have another 2TB disk lying around, to help with what I want to achieve.. which is to replace the current 3TB parity disk with one of the current 3TB data drives. Am I correct in thinking the steps below would be the process for achiving this swap? Add teh spare 2TB drive to the array and assign to data Stop the array Unassign the 3TB data drive that will become the parity disk Start the array - I'm assuming at this stage the parity drive will start to populate the remaining data drives with the data that was stored on the drive being unassgined? Once the data is sync'd and healthy run through the process of replacing the parity drive: Stop the array Unassign the current parity drive Assign the now unassigned 3TB old data drive to parity Start the array and let the parity rebuild I know ideally I should add a new drive of bigger capacity for the parity, however that's not an option at the moment and this is a secondary unraid device on the network. Thanks in advance

Just to confirm the 800GB+ backup worked without dropping the samba services, when the faulty DIMM was removed.

Currently running a memtest and have found one faulty DIMM. Will re-run the backup task with known good sticks and report back.

Hi guys, I've got a ~800GB copy going from a Windows machine to my Unraid server. Between 90mins and 2hrs in the samba shares all vanish and the file transfer fails. I've had the odd occurrence of the shares disappearing prior to this, however this file copy activity consistently causes the shares to go. I've tried restarting samba using /etc/rc.d/rc.samba restart and can see samba starting, but no shares come back without a reboot. Any help and ideas would be greatly appreciated. Diag dump attached hydra-diagnostics-20230209-1203.zip

Yes. I found a work around by using WinSCP to grab the files

Is there similar tuning that can be done to improve performance copying from unraid SMB to Windows? Trying to copy back some photos (only 1.4GB/930 files) and getting big bouts of no activity, it's taking ~25mins to copy the files.