jc179

Hi there, Hoping someone might be able to help with this... I have unraid 6.10.3 with the latest devtools installed, and cc1 found under /usr/libexec/gcc/x86_64-slackware-linux/9.2.0 seems to be wanting the libisl.so.22 , and not the newer libisl.so.23 I did turn off all addins from within the Dev Pack tool, and apply, reboot, and turn them all backon, apply, and reboot. See below output for LDD root@cerebellum:/usr/libexec/gcc/x86_64-slackware-linux/9.2.0# cc1 cc1: error while loading shared libraries: libisl.so.22: cannot open shared object file: No such file or directory root@cerebellum:/usr/libexec/gcc/x86_64-slackware-linux/9.2.0# root@cerebellum:/usr/libexec/gcc/x86_64-slackware-linux/9.2.0# ldd cc1 linux-vdso.so.1 (0x00007ffeb848b000) libisl.so.22 => not found libmpc.so.3 => /usr/lib64/libmpc.so.3 (0x00001485e4b9f000) libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x00001485e48f4000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00001485e487b000) libdl.so.2 => /lib64/libdl.so.2 (0x00001485e4876000) libz.so.1 => /lib64/libz.so.1 (0x00001485e485c000) libm.so.6 => /lib64/libm.so.6 (0x00001485e4712000) libc.so.6 => /lib64/libc.so.6 (0x00001485e4533000) /lib64/ld-linux-x86-64.so.2 (0x00001485e4bca000) root@cerebellum:/usr/libexec/gcc/x86_64-slackware-linux/9.2.0# See LIBISL /usr/lib64/libisl.so.23 /usr/lib64/libisl.so.23.1.0 root@cerebellum:/usr/libexec/gcc/x86_64-slackware-linux/9.2.0# ldconfig -p | grep -i isl libisl.so.23 (libc6,x86-64) => /usr/lib64/libisl.so.23 thanks for any advice tips or tricks to resolve this... Jonathan

Messing around further, I tried using a loop device back to the /dev/fioa, but even *that* doesn't show up in the Unraid GUI, lsscsi also doesn't see it, probably because it is major #7, (major #8, hdd block devices, losetup won't do it ). again, all a guess... mknod /dev/sdn b 7 200 losetup /dev/sdn /dev/fioa udevadm control --reload-rules udevadm trigger root@cerebellum:/# fdisk -l /dev/sdn Disk /dev/sdn: 596.5 GiB, 640000000000 bytes, 1250000000 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 5D116A01-F6AC-45FB-94A9-C3881252FA51 Device Start End Sectors Size Type /dev/sdn1 34 32767 32734 16M Microsoft reserved /dev/sdn2 32768 1249996799 1249964032 596G Microsoft basic data root@cerebellum:/# Perhaps if we could modify the error checking of losetup (opensource recompile), so that this would work, then this might show up, with the caveat of a hefty performance impact, but I'd still use it honestly... crude quick speed test: root@cerebellum:/# dd if=/dev/fioa of=/dev/null bs=1024k count=20000 20000+0 records in 20000+0 records out 20971520000 bytes (21 GB, 20 GiB) copied, 14.4936 s, 1.4 GB/s root@cerebellum:/# dd if=/dev/sdn of=/dev/null bs=1024k count=20000 20000+0 records in 20000+0 records out 20971520000 bytes (21 GB, 20 GiB) copied, 24.5716 s, 853 MB/s root@cerebellum:/# This fails... root@cerebellum:/dev# mknod /dev/sdo b 8 200 root@cerebellum:/dev# losetup /dev/sdo /dev/fioa losetup: /dev/sdo: failed to set up loop device: No such device or address Maybe someone else has another idea to try, maybe emhttpd could be patched to recognize the fioa device or something else... I don't know... sucks... Just want to make this work, id even take half speed... lol. Is like pandora's magic box here... Jonathan

You know what, I was so fixated with that I forgot to look at what the script is actually doing, and looked in the wrong place. I do see the card shows up under /dev/disk/by-id !!! root@cerebellum:/dev/disk/by-id# ls -al total 0 drwxr-xr-x 2 root root 1100 Jan 5 14:59 ./ drwxr-xr-x 7 root root 140 Dec 30 13:17 ../ lrwxrwxrwx 1 root root 10 Jan 5 14:59 fio-0630fa34-0505-1441-9d5b-6d79afe74709 -> ../../fioa lrwxrwxrwx 1 root root 11 Jan 5 14:59 fio-0630fa34-0505-1441-9d5b-6d79afe74709-part1 -> ../../fioa1 lrwxrwxrwx 1 root root 11 Jan 5 14:59 fio-0630fa34-0505-1441-9d5b-6d79afe74709-part2 -> ../../fioa2 (I remove all other unecessary info here, eg other disks we're not interested in). Checking in the Unraid GUI, there is nothing new. I didn't have any new unassigned disks, I even stopped the array to have a look, no changes... dang. Was really hoping this would work! Maybe Unraid 6.9 might behave differently? Will see if I can give that a try at some point... There are indeed two partitions on my fio card, and this has mapped them correctly - I can mount and talk to the fio card a-ok as well. The issue might lie that even using the by-id, when mounted, seems to revert back to a /dev/fioa device.... mount /dev/disk/by-id/fio-0630fa34-0505-1441-9d5b-6d79afe74709-part2 /a /dev/fioa2 597G 113M 596G 1% /a /dev/fioa2 on /a type fuseblk (rw,allow_other,blksize=4096) Wish I had better news... Jonathan

Tried compiling with the latest GIT release (v4.2) as I am kernel 4.19 on unraid 6.8.3 still. Managed to compile it, but needed to modify the .sh scripts - I assume no one else has run into this, so it must be something weird with my unraid build env. Basically some instances of "cat" seems to be broken reporting 'standard output: No such file or directory'.... Very odd, not going to dwell on it for now, managed to work around this, and load the module (left some notes below as to what I did) . I added the script you linked to my /lib/udev/rules.d/95-fio.rules , but don't see any new devices show up. There wasn't any info on how exactly to use this either, so I may need to run something to kick off the scirpt and create the new udev devices. I am a little tempted to manually populate and run the below and just see, but I will wait : /usr/bin/fio-status --field iom.format_uuid /dev/%k", SYMLINK+="disk/by-id/fio-%c /usr/bin/fio-status --field iom.format_uuid /dev/%P", SYMLINK+="disk/by-id/fio-%c-part%n If interested, here is the error output from the make make[1]: Leaving directory '/mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16' ./kfio_config.sh -a x86_64 -o include/fio/port/linux/kfio_config.h -k /lib/modules/4.19.107-Unraid/build -p -d /mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16/kfio_config -l 0 cat: standard output: No such file or directory 1609869599.051 Exiting Preserving configdir due to '-p' option: /mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16/kfio_config make: *** [Makefile:88: include/fio/port/linux/kfio_config.h] Error 1 kfio_config.sh complains that "cat: standard output: No such file or directory" which is ridiculous, as cat certainly exists, and is in the path... root@cerebellum:/mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16# env | grep PATH MANPATH=/usr/local/man:/usr/man NODE_PATH=/usr/lib64/node_modules PATH=.:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin root@cerebellum:/mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16# which cat /usr/bin/cat Here is the line which it's stopping at, I added an echo to identify: : "${TMP_OUTPUTFILE:=${CONFIGDIR}/kfio_config.h}" echo "cat instance 5" cat <<EOF if I modify the line with the cat commands in kfio_config.sh: from this "cat <<EOF" to "echo <<EOF" ... to use echo instead of cat, we progress !! So the change now looks like: : "${TMP_OUTPUTFILE:=${CONFIGDIR}/kfio_config.h}" echo "cat instance 5" #cat <<EOF echo <<EOF and re-run the line from the make file script, it completes now! ./kfio_config.sh -a x86_64 -o include/fio/port/linux/kfio_config.h -k /lib/modules/4.19.107-Unraid/build -p -d /mnt/user/dev/iomemory-vsl/root/usr/src/iomemory-vsl-3.2.16/kfio_config -l 0 So, stop and resume the original make command, which finally finishes: Ok: altered version for iomemory-vsl.ko appended 2a18ca0 ### I don't see any new /dev/sdX devices, I assume the linked script goes somewhere like /lib/udev/rules.d/95-fio.rules ### insmod iomemory-vsl.ko ## dmesg -T | tail -100 [Tue Jan 5 13:38:33 2021] <6>fioinf VSL configuration hash: 8f82ea05bdf1195cb400fb48e4ef09fc49b3c1aa [Tue Jan 5 13:38:33 2021] <6>fioinf [Tue Jan 5 13:38:33 2021] <6>fioinf Copyright (c) 2006-2014 Fusion-io, Inc. (acquired by SanDisk Corp. 2014) [Tue Jan 5 13:38:33 2021] <6>fioinf Copyright (c) 2014-2016 SanDisk Corp. and/or all its affiliates. (acquired by Western Digital Corp. 2016) [Tue Jan 5 13:38:33 2021] <6>fioinf Copyright (c) 2016-2018 Western Digital Technologies, Inc. All rights reserved. [Tue Jan 5 13:38:33 2021] <6>fioinf For Terms and Conditions see the License file included [Tue Jan 5 13:38:33 2021] <6>fioinf with this driver package. [Tue Jan 5 13:38:33 2021] <6>fioinf [Tue Jan 5 13:38:33 2021] <6>fioinf ioDrive driver 3.2.16.1731 4870ad45b7ea 2a18ca0 a loading... [Tue Jan 5 13:38:33 2021] <6>fioinf ioDrive 0000:04:00.0: mapping controller on BAR 5 [Tue Jan 5 13:38:33 2021] <6>fioinf ioDrive 0000:04:00.0: MSI enabled [Tue Jan 5 13:38:33 2021] <6>fioinf ioDrive 0000:04:00.0: using MSI interrupts [Tue Jan 5 13:38:33 2021] <6>fioinf ioDrive 0000:04:00.0.0: Starting master controller [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Adapter serial number is 602555 [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Board serial number is 602555 [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Adapter serial number is 602555 [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Default capacity 640.000 GBytes [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Default sector size 512 bytes [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Rated endurance 10.00 PBytes [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: 85C temp range hardware found [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Firmware version 7.1.17 116786 (0x700411 0x1c832) [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Platform version 10 [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Firmware VCS version 116786 [0x1c832] [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Firmware VCS uid 0xaeb15671994a45642f91efbb214fa428e4245f8a [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Powercut flush: Enabled [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: PCIe power monitor enabled (master). Limit set to 24.750 watts. [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Thermal monitoring: Enabled [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0.0: Hardware temperature alarm set for 85C. [Tue Jan 5 13:38:34 2021] <6>fioinf ioDrive 0000:04:00.0: Found device fct0 (Fusion-io ioDrive 640GB 0000:04:00.0) on pipeline 0 [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: probed fct0 [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: sector_size=512 [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: setting channel range data to [2 .. 4095] [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: Found metadata in EBs 168-169, loading... [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: setting recovered append point 169+198180864 [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: Creating device of size 640000000000 bytes with 1250000000 sectors of 512 bytes (213422 mapped). [Tue Jan 5 13:38:36 2021] fioinf Fusion-io ioDrive 640GB 0000:04:00.0: Creating block device fioa: major: 254 minor: 0 sector size: 512... [Tue Jan 5 13:38:36 2021] fioa: fioa1 fioa2 [Tue Jan 5 13:38:36 2021] <6>fioinf Fusion-io ioDrive 640GB 0000:04:00.0: Attach succeeded. root@cerebellum:/mnt/user/dev# /usr/bin/fio-status Found 1 ioMemory device in this system Driver version: 3.2.16 build 1731 Adapter: Single Adapter Fusion-io ioDrive 640GB, Product Number:FS1-004-640-CS, SN:602555, FIO SN:602555 External Power: NOT connected PCIe Power limit threshold: 24.75W Connected ioMemory modules: fct0: Product Number:FS1-004-640-CS, SN:602555 fct0 Attached ioDrive 640GB, Product Number:FS1-004-640-CS, SN:602555 PCI:04:00.0, Slot Number:5 Firmware v7.1.17, rev 116786 Public 640.00 GBytes device size Internal temperature: 54.14 degC, max 54.63 degC Reserve space status: Healthy; Reserves: 100.00%, warn at 10.00% Contained VSUs: fioa: ID:0, UUID:0630fa34-0505-1441-9d5b-6d79afe74709 fioa State: Online, Type: block device ID:0, UUID:0630fa34-0505-1441-9d5b-6d79afe74709 640.00 GBytes device size

Thanks for the info! Jonathan

Hi, I have a few disks that I want to copy to my unraid array, by connecting them upto the same machine to save time, however I can't find mdadm, or any equivalent tool to create the array temporarly on my unraid. Network speed is going at a whopping 22 mb a sec, ill probably die of old age before it finishes... Is there a prebuild package that would have these utilities, or I need to find binaries that will work on my current unraid setup to just do a quick mdadm --assemble command so I can mount the MD device, and copy the data at a reasonable speed ? thanks, Jonathan

deleted - redundant info

Hi New around here, but hoping to get some help with another unusual issue with unraid in 6.8.3 and seagate SMR hard drives ST8000AS0002 (/dev/sdg and /dev/sdh), and unraid's disk settings. What's currently happening is in dmesg/ syslog, I find the below error messages by: 1. allowing things to idle on unraid, and either logging in to, or refreshing the webUI and experiencing long hangs populating "Unassigned Devices" - where these two SMR hdd's are currently mounted. 2. by running /usr/bin/dd bs=1 count=48 skip=462 if=/dev/sdh 2>/dev/null | /bin/sum | / bin/awk '{print }' ... on a terminal when those disks have been inactive for some time. Messages found related to hard drive commands rx/td'd : Syslog: Apr 27 10:24:02 Tower unassigned.devices: Error: shell_exec(/usr/bin/dd bs=446 count=1 if=/dev/sdg 2>/dev/null | /bin/sum | /bin/awk '{print }') took longer than 5s! Apr 27 10:24:07 Tower kernel: sd 15:0:5:0: [sdg] tag#8357 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Apr 27 10:24:07 Tower kernel: sd 15:0:5:0: [sdg] tag#8357 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 Apr 27 10:24:07 Tower kernel: print_req_error: I/O error, dev sdg, sector 0 Apr 27 10:24:07 Tower unassigned.devices: Error: shell_exec(/usr/bin/dd bs=1 count=48 skip=462 if=/dev/sdg 2>/dev/null | /bin/sum | / bin/awk '{print }') took longer than 5s! Apr 27 10:24:14 Tower unassigned.devices: Error: shell_exec(/usr/bin/dd bs=446 count=1 if=/dev/sdh 2>/dev/null | /bin/sum | /bin/awk '{print }') took longer than 5s! Apr 27 10:24:19 Tower kernel: sd 15:0:6:0: [sdh] tag#8259 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 Apr 27 10:24:19 Tower kernel: sd 15:0:6:0: [sdh] tag#8259 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 Apr 27 10:24:19 Tower kernel: print_req_error: I/O error, dev sdh, sector 0 Apr 27 10:24:19 Tower unassigned.devices: Error: shell_exec(/usr/bin/dd bs=1 count=48 skip=462 if=/dev/sdh 2>/dev/null | /bin/sum | / bin/awk '{print }') took longer than 5s! dmesg [Mon Apr 27 10:24:07 2020] sd 15:0:5:0: [sdg] tag#8357 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 [Mon Apr 27 10:24:07 2020] sd 15:0:5:0: [sdg] tag#8357 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 [Mon Apr 27 10:24:07 2020] print_req_error: I/O error, dev sdg, sector 0 [Mon Apr 27 10:24:19 2020] sd 15:0:6:0: [sdh] tag#8259 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 [Mon Apr 27 10:24:19 2020] sd 15:0:6:0: [sdh] tag#8259 CDB: opcode=0x88 88 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 [Mon Apr 27 10:24:19 2020] print_req_error: I/O error, dev sdh, sector 0 [Mon Apr 27 18:53:49 2020] sd 15:0:5:0: [sdg] tag#7400 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 [Mon Apr 27 18:53:49 2020] sd 15:0:5:0: [sdg] tag#7400 CDB: opcode=0x88 88 00 00 00 00 00 00 04 09 60 00 00 00 20 00 00 [Mon Apr 27 18:53:49 2020] print_req_error: I/O error, dev sdg, sector 264544 [Mon Apr 27 18:54:35 2020] sd 15:0:6:0: [sdh] tag#7681 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 [Mon Apr 27 18:54:35 2020] sd 15:0:6:0: [sdh] tag#7681 CDB: opcode=0x88 88 00 00 00 00 00 00 04 09 60 00 00 00 20 00 00 [Mon Apr 27 18:54:35 2020] print_req_error: I/O error, dev sdh, sector 264544 [Mon Apr 27 21:42:55 2020] sd 15:0:6:0: attempting task abort! scmd(0000000026d5a722) [Mon Apr 27 21:42:55 2020] sd 15:0:6:0: [sdh] tag#704 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 4 0 e5 00 I do have unraid "Default spin down delay: to never", and I don't have anything setup per disk to spin down either. I have managed to repeat it somewhat using hdparm -Y /dev/sdh or /dev/sdg, followed by -C to check the state. When the reported state comes back as "standby" and I make an attempt to read the hard drive (eg use the DD command above, or anything else, such as a ls, it hangs for ~10 seconds before it responds, followed by those messages in the syslog/dmesg. root@Tower:~# hdparm -Y /dev/sdh /dev/sdh: issuing sleep command root@Tower:~# hdparm -C /dev/sdh /dev/sdh: drive state is: standby root@Tower:~# hdparm -C /dev/sdh /dev/sdh: drive state is: active/idle root@Tower:~# hdparm -Y /dev/sdh /dev/sdh: issuing sleep command gets from dmesg [Mon Apr 27 21:45:57 2020] sd 15:0:6:0: [sdh] tag#1021 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [Mon Apr 27 21:45:57 2020] sd 15:0:6:0: [sdh] tag#1021 Sense Key : 0x2 [current] [Mon Apr 27 21:45:57 2020] sd 15:0:6:0: [sdh] tag#1021 ASC=0x4 ASCQ=0x2 [Mon Apr 27 21:45:57 2020] sd 15:0:6:0: [sdh] tag#1021 CDB: opcode=0x88 88 00 00 00 00 00 00 59 92 38 00 00 01 c8 00 00 [Mon Apr 27 21:45:57 2020] print_req_error: I/O error, dev sdh, sector 5870136 [Mon Apr 27 21:47:02 2020] sd 15:0:6:0: attempting task abort! scmd(000000002be3a761) [Mon Apr 27 21:47:02 2020] sd 15:0:6:0: tag#913 CDB: opcode=0x0 00 00 00 00 00 00 [Mon Apr 27 21:47:02 2020] scsi target15:0:6: handle(0x0010), sas_address(0x50019400005e6207), phy(7) [Mon Apr 27 21:47:02 2020] scsi target15:0:6: enclosure logical id(0x50019400005e623f), slot(7) [Mon Apr 27 21:47:03 2020] sd 15:0:6:0: task abort: SUCCESS scmd(000000002be3a761) [Mon Apr 27 21:47:03 2020] sd 15:0:6:0: Power-on or device reset occurred [Mon Apr 27 21:47:04 2020] sd 15:0:6:0: Power-on or device reset occurred [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1337 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x00 [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1337 CDB: opcode=0x88 88 00 00 00 00 00 00 c8 2a 00 00 00 07 a8 00 00 [Mon Apr 27 21:47:18 2020] print_req_error: I/O error, dev sdh, sector 13117952 [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1334 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1334 Sense Key : 0x2 [current] [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1334 ASC=0x4 ASCQ=0x2 [Mon Apr 27 21:47:18 2020] sd 15:0:6:0: [sdh] tag#1334 CDB: opcode=0x88 88 00 00 00 00 00 00 c8 31 a8 00 00 02 58 00 00 [Mon Apr 27 21:47:18 2020] print_req_error: I/O error, dev sdh, sector 13119912 Both of these hard drives pass smart tests and diags, and didn't have issues when coping the data off them to the array, nor in the previous enclosure - this has just started appearing after they've been 'idle'. Unable to disable any "seagate" related power down stuff: root@Tower:~# hdparm -Z /dev/sdg /dev/sdg: disabling Seagate auto powersaving mode HDIO_DRIVE_CMD(seagatepwrsave) failed: Input/output error root@Tower:~# hdparm -Z /dev/sdh A friend has suggested to try them on an onboard controller, as mine is a LSI SAS2308 PCI-Express Fusion-MPT SAS-2 with already the latest firmware. Any other ideas? thanks, Jonathan

Certainly odd - managed to fix it by updating the firmware on the LSI Card For anyone else who runs into this Before: After; The HGST's are now at 3.0 Gb/s Oddly stil see the ATA messages on startup, suspect that it is the onboard SATA ports causing this, will disable them and see if it clears Thanks for the help/ ideas - Will retest things now! Jonathan

Thanks for asking, but Yes, the hardware is 100% reliable, it has been used the last ~4 years by a Linux software raid 6 array of 6 disks. there is no issue /w the controller or SAS expander, zero issues. Note this only happens with unraid 6.8.3 booted - Slackware, and even Ubuntu I tried last night do not show this error, and the drives negotiate at 3.0 Gb/s. I suspect there maybe a bug being caused with another module that's loading or the 2308 driver itsself in the kernel. I have tried recreating unraid 6.8.3, and that does not solve the issue either. Thanks, Jonathan

Greetings fellow unraiders: I'm trying to troubleshoot an issue I'm having with poor performance in unraid after migrating to it, but first I noticed that in unraid my Hitachi 8T HDD only negotiate at SATA 1.5 Gb/s, instead of SATA 3.0 Gb/sec as they we previously in slackware 14. Also, while benchmarking the drives, the 8T Hitachi drives, they would not benchmark over 130 meg/sec using "diskspeed addin " or watching on command line with "iostat -m 5". Further checking revealed that they negotiate at Sata 1.5 Gb/s instead as Sata 3.0 Gb/sec when running Slackware 14 on this hardware previously (keep in mind, only change = OS at this point, and boot device). I realize this isn't going to make a large difference either in my overall slow performance issue (see below for more details). Are there any kernel parameters I can pass, or would I need to recompile the kernel using the below "known" good version? I do get this on unraid boot (not slackware), and am not certain if its related to an invalid response receivd back from the disks? All of the other disks attached negotiate at Sata 3.0.. [ 24.694680] mlx4_en 0000:04:00.0: Activating port:2 [ 24.695661] mlx4_en: 0000:04:00.0: Port 2: Using 12 TX rings [ 24.695923] mlx4_en: 0000:04:00.0: Port 2: Using 8 RX rings [ 24.696336] mlx4_en: 0000:04:00.0: Port 2: Initializing port [ 26.927642] mlx4_en: eth1: Link Up [ 26.982588] mlx4_en: eth1: Link Down [ 26.982918] mlx4_en: eth2: Link Up [ 27.137470] mlx4_en: eth1: Link Up \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ [ 27.545855] ata8.00: qc timeout (cmd 0xa1) [ 27.546122] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 27.546402] ata14.00: qc timeout (cmd 0xa1) [ 27.855354] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 28.046151] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 28.856493] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 38.297869] ata8.00: qc timeout (cmd 0xa1) [ 38.298136] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 38.608480] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 39.321861] ata14.00: qc timeout (cmd 0xa1) [ 39.822484] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 40.632478] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 69.017833] ata8.00: qc timeout (cmd 0xa1) [ 69.018099] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 69.328473] ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 71.065879] ata14.00: qc timeout (cmd 0xa1) [ 71.566557] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 72.376473] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ 73.090854] BTRFS: device fsid 7287fbd8-04ca-4508-b947-73813bcf236d devid 1 transid 61 /dev/sdj1 [ 73.118785] BTRFS: device fsid 7287fbd8-04ca-4508-b947-73813bcf236d devid 3 transid 61 /dev/sdl1 [ 73.124181] BTRFS: device fsid 7287fbd8-04ca-4508-b947-73813bcf236d devid 2 transid 61 /dev/sdi1 [ 73.134152] BTRFS: device fsid 7287fbd8-04ca-4508-b947-73813bcf236d devid 4 transid 61 /dev/sdk1 [ 74.668886] sky2: driver version 1.30 [ 74.668998] sky2 0000:06:00.0: Yukon-2 EC Ultra chip revision 3 [ 74.669209] sky2 0000:06:00.0 eth0: addr 20:cf:30:66:b9:a3 [ 74.691230] mlx4_core: Mellanox ConnectX core driver v4.0-0 Under unraid 6.8.3 (4.19.107-Unraid) : root@Tower:~# smartctl --all /dev/sdb smartctl 7.1 2019-12-30 r5022 [x86_64-linux-4.19.107-Unraid] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: HGST HDN728080ALE604 Serial Number: R6GSE49Y LU WWN Device Id: 5 000cca 263caa5db Firmware Version: A4GNW91X User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.1, 6.0 Gb/s (current: 1.5 Gb/s) <================= Under slackware 14 (kernel Linux san 4.4.14) root@san:/# smartctl --all /dev/sdb smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.14] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: HGST HDN728080ALE604 Serial Number: R6GSE49Y LU WWN Device Id: 5 000cca 263caa5db Firmware Version: A4GNW91X User Capacity: 8,001,563,222,016 bytes [8.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 7200 rpm Form Factor: 3.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4 SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) <================= Local Time is: Fri Apr 10 00:00:08 2020 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Entire issue: While I'm trying to restore my backup to the disks I freed up for this array, things are going uber slow, about 50-70 mb/sec tops, if I try to do a directory listing, it can take minutes before *anything* comes back! - Drives were pre-cleared, and parity was built - The exact hardware before running Linux raid6 software raid would do 200+ mb/sec over 10 gig for large files. I've run the "fix common problems" and "ca turbo write" but not really any changes. - Spec is Xeon(R) CPU X5650, 24 G ram, LSI SAS2303/ Broadcom / LSI SAS9217-4i4e connected to a SE3016 Rackable array /w the above hitachi disks in it. Thanks for any help Jonathan

Hi I was looking for a way to modify the udev rules upon boot of unraid, using the "persistent rules file". However upon pulling the bzroot apart, and re-packing it with a small change to the startup script to create the "70-persistent-net.rules", the udev rules are ignored. Though I can see my expected changes are reflected in the file at the time of boot (I add cat /etc/udev/xxx upon boot to see), the boot up console shows me they haven't worked (ixgbe loads first before e1000).... argh! :bandhead: Looking into various startup files, and config files, I noticed there was another "udev" and rules under /dev/.udev - so I tested creating a rules file there too - no luck. I modified the /etc/rc.d/rc.S to create the following files 1. /etc/udev/rules.d/70-persistent-net.rules 2. /dev/.udev/rules.d/70-persistent-net.rules ...I tried creating this file before and after /etc/rc.d/rc.S calls udev startup "/etc/rc.d/rc.udev start", and no luck still. dmesg reveals the 10gig card is still eth0. I am not sure why the udev persistent rules aren't read in when udev is started. In either case I had to do something aweful as a temporary work around until I can figure this out.... rename the ixgbe.ko until the system boots, and then rename it back and modprobe it. I've looked but don't see much success with udev related on the forms, any ideas how to get the udev to read the persistent rules file?

Based on the info provided above, and the messages, I'd suspect you have a bad block that hasn't been remapped, or when this bad block occurred a/some file(s) with-in couchpotato was corrupted. Ideally disks should handle this in the background, *but* if it can't read the block, its possible the data is corrupt. Since sabnzb is ok (assume perhaps python is OK), and perhaps just your couch potato is cooked. Maybe VI the .PY file and see if you anything. In the meantime before messing about too much: #1. I'd backup the filesystem where you have this installed to #2. Run a scan, which checks for bad blocks, one example assuming ext2: e2fsck -c /dev/sdb1 #3. If all is ok, reinstall couch potato to replace corrupted files, if not, dig further, maybe a python lib is nackered. hope that helps Jonathan

Not a bad idea, I hadn't tried that.... but sadly after a quick test, it does the same. root@Tower:/etc/udev/rules.d# cat 70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key. # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 (ixgbe) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1b:21:5f:cf:ec", ATTR{dev_id}=="0x0", ATTR{type}=="1", K ERNEL=="eth*", NAME="eth0" # PCI device 0x8086:/sys/devices/pci0000:00/0000:00:19.0 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:b3:13:49:d1", ATTR{dev_id}=="0x0", ATTR{type}=="1", K ERNEL=="eth*", NAME="eth1" root@Tower:/etc/udev/rules.d# dmesg | grep eth reboot: HP Compaq Laptop series board detected. Selecting BIOS-method for reboots. ACPI Error: Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff880073448de8), AE_ALREADY_EXISTS (20140926/psparse-53 6) e1000e 0000:00:19.0 eth1: (PCI Express:2.5GT/s:Width x1) 00:25:b3:13:49:d1 e1000e 0000:00:19.0 eth1: Intel® PRO/1000 Network Connection e1000e 0000:00:19.0 eth1: MAC: 8, PHY: 8, PBA No: FFFFFF-0FF ixgbe 0000:01:00.0 eth0: NIC Link is Up 10 Gbps, Flow Control: RX/TX root@Tower:/etc/udev/rules.d# uname -a Linux Tower 3.18.5-unRAID #3 SMP Thu Feb 19 09:21:26 PST 2015 x86_64 Intel® Core2 Duo CPU E8400 @ 3.00GHz Genuin eIntel GNU/Linux root@Tower:/etc/udev/rules.d#

Hello I'm having an issue with unraid's choice of which network card it picks first. I have eth0, and eth1, and of course the one I want to use as "primary" interface for the unraid is eth1, instead of eth0. I've looked at http://lime-technology.com/forum/index.php?topic=38487.15 Which had shed some light on how to deal with some of this, but nothing has worked. I've also tried "cating the 70-persistent-net.rules" into /etc/udev/70-persistent-net.rules on boot and issuing a udevadm trigger and udevadm restart? but nothing takes effect. My current file after unraid boot looks like this; # PCI device 0x8086:0x10c7 (ixgbe) SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:1b:21:5f:cf:ec, ATTR{dev_id}==0x0, ATTR{type}==1, KERNEL==eth*, NAME=eth1 # PCI device 0x8086:0x10de (e1000e) SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:25:b3:13:49:d1, ATTR{dev_id}==0x0, ATTR{type}==1, KERNEL==eth*, NAME=eth0 And I want to make the following happen: # PCI device 0x8086:0x10c7 (ixgbe) SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:1b:21:5f:cf:ec, ATTR{dev_id}==0x0, ATTR{type}==1, KERNEL==eth*, NAME=eth0 # PCI device 0x8086:0x10de (e1000e) SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:25:b3:13:49:d1, ATTR{dev_id}==0x0, ATTR{type}==1, KERNEL==eth*, NAME=eth1 As you know the system isn't a real partition, so all changes after boot up are lost... In theory, if I xz bzroot, and then cpio -idv, add my file to the "etc/udev/rules.d" and stuff it back together would it work, or is there some annoying checksum? Aside from that or bashing my head against the desk doing a slackware-unraid setup, which I think I saw a guide how-to-do, is there any easier option? Can I somehow pull apart the image, update or make the 70-persistent-net.rules file static and get going? Thanks, Jonathan