nick5429

@gfjardim Hey this is happening to me now as well [2 years later]. Unraid 6.9.3, plugin version 2021.04.11 [up-to-date] I noticed 'lsof' was pegging an entire cpu to 100%; investigated and it's coming from /etc/rc.d/rc.diskinfo From /var/log/diskinfo.log , it looks like this benchmark is being run continuously in a loop, with no delay/sleep between iterations Mon Oct 18 22:17:49 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/SanDiskSSD' 2>/dev/null | tail -n +2 | wc -l) took 14.509439s. Mon Oct 18 22:18:03 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/VolatileSSD' 2>/dev/null | tail -n +2 | wc -l) took 13.332904s. Mon Oct 18 22:18:47 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/SanDiskSSD' 2>/dev/null | tail -n +2 | wc -l) took 13.167924s. Mon Oct 18 22:19:00 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/VolatileSSD' 2>/dev/null | tail -n +2 | wc -l) took 12.680031s. Mon Oct 18 22:19:44 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/SanDiskSSD' 2>/dev/null | tail -n +2 | wc -l) took 12.882862s. Mon Oct 18 22:19:58 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/VolatileSSD' 2>/dev/null | tail -n +2 | wc -l) took 14.628200s. Mon Oct 18 22:20:44 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/SanDiskSSD' 2>/dev/null | tail -n +2 | wc -l) took 14.887803s. Mon Oct 18 22:20:57 EDT 2021: benchmark: shell_exec(lsof -- '/mnt/disks/VolatileSSD' 2>/dev/null | tail -n +2 | wc -l) took 13.041714s. Those drives are mounted by Unassigned Devices. I'm not sure what this benchmark was trying to accomplish, as I don't have any preclear's running, and haven't since a reboot.

I have two separate dockers running delugevpn on my unraid machine via PIA vpn. They both worked well simultaneously with PIA's 'old' network and deluge ~2.0.3. After upgrading to the newest delugevpn docker and PIA's 'nextgen' network (identical .ovpn files for each), only one of them works properly. One works perfectly, the other gets stuck on Tracker Status: 'announce sent' (vs 'announce ok'), with the exact same public linux test torrent (or with any other torrent). The logs appear to show that both are properly getting separate forwarded ports setup with no obvious errors, and I don't think I changed anything other than what was required to move to nextgen PIA vpn. They're setup basically identically except for different download folders, and different host port mappings (went port+1 for each). Both running in network bridge mode. Any ideas?

How can I select multiple drives at once to process in a 'scatter' operation? I have 5 disks that I want to move all the data off and decommission; doing them one at a time (and needing to circle back and remember to move on to the next one at the appropriate time) is going to be a hassle.

Hm. Well, I blew away the old installation, and re-selected the packages (being careful to only select things that weren't already installed by the underlying unraid system), and it seems fine. Good for me, but doesn't fully solve the answer of whether it was a problem with my flash, or a problem with some built-in package system being replaced. If I feel bold (and feel like dealing with another crashed system), maybe I'll re-enable having DevPack install all the old packages later

Something in this prevents my server from booting on unraid 6.4.1 Took a couple hours for me to narrow it down to this plugin. This was working fine with my setup on 6.3.5 and I didn't enable/disable any packs. Here's what I've got in DevPack.cfg: attr-2_4_47="no" binutils-2_27="yes" bzip2-1_0_6="yes" cxxlibs-6_0_18="yes" expat-2_2_0="no" flex-2_6_0="no" gc-7_4_2="yes" gcc-5_4_0="yes" gdbm-1_12="no" gettext-0_19_8_1="no" glib2-2_46_2="no" glib-1_2_10="yes" glibc-2_24="yes" gnupg-1_4_21="no" gnutls-3_5_8="yes" gpgme-1_7_1="no" guile-2_0_14="yes" json-c-0_12="no" json-glib-1_2_2="no" kernel-headers-4_4_38="yes" libelf-0_8_13="no" libevent-2_1_8="no" libgcrypt-1_7_5="no" libgpg-error-1_23="no" libjpeg-turbo-1_5_0="no" libmpc-1_0_3="yes" libnl-1_1_4="no" libpcap-1_7_4="no" libunistring-0_9_3="no" libX11-1_6_4="yes" make-4_2_1="yes" ncurses-5_9="yes" openssl-1_0_2k="no" pcre-8_39="no" pkg-config-0_29_1="yes" sqlite-3_13_0="no" tcl-8_6_5="yes" tclx-8_4_1="no" tk-8_6_5="no" xproto-7_0_29="no" xz-5_2_2="yes" zlib-1_2_8="yes" This caused a similar symptom as in Unfortunately, I wasn't able to capture a more complete log, since it completely locks up the system. The files in /boot/config/plugins/DevPack/packages/6.4 that it managed to download before locking up are: binutils-2.27-x86_64-2.txz* bzip2-1.0.6-x86_64-1.txz* cxxlibs-6.0.18-x86_64-1.txz* gc-7.4.2-x86_64-3.txz* gcc-5.4.0-x86_64-1.txz* glib-1.2.10-x86_64-3.txz* glibc-2.24-x86_64-2.txz* gnutls-3.5.8-x86_64-1.txz* guile-2.0.14-x86_64-1.txz* kernel-headers-4.4.38-x86-1.txz* libX11-1.6.4-x86_64-1.txz* libmpc-1.0.3-x86_64-1.txz* make-4.2.1-x86_64-1.txz* ncurses-5.9-x86_64-4.txz* packages-desc* packages.json* pkg-config-0.29.1-x86_64-2.txz* tcl-8.6.5-x86_64-2.txz* xz-5.2.2-x86_64-1.txz* zlib-1.2.8-x86_64-1.txz* Unfortunately, they're all timestamped in the same second, so I'm unable to determine processing order that way. PS -- this is super handy! Hope you get it working again soon, and thanks

I tried it both ways. When I wasn't seeing any uploading on my usual private torrents, I found the most active public torrent possible as a test -- and I see virtually no upload there either

So I've got everything configured and set up, and am getting great download speeds through the PIA Netherlands endpoint (20+ MB/sec) -- but my upload is all-but-nonexistent. I'm on a symmetric gigabit fiber connection (1000Mbit/sec upload and download). "Test active port" in deluge comes back with a happy little green ball. Strict port forwarding in the container config is enabled. I loaded up about 10 test torrents on 3 different private trackers with a moderate number of peers, and see zero upload (as in, not even a number shown in the 'upload' column). Just for funsies, I pulled up a public torrent with 60 seeds and 600 leechers and downloaded the whole thing. I have a total of 30 KB/sec upload on that torrent. Something is clearly wrong here. I've seen several other comments about this throughout the thread, but no resolution. Does uploading work correctly for anyone using this with PIA??

It's more that -- to achieve true end-to-end fault tolerance, you must have ECC ram. The automatic checksumming that ZFS implements is still an enormous improvement in data integrity / bitrot detection, even without ECC ram. And no, the various checksum snapshot projects that have been implemented for unraid are not a comparable solution. They're (perhaps) better than nothing, but are still vastly inferior to having it built into the filesystem

Wow, they seem to be the only retailer who sells this product? Contacted them for a shipping quote to the US, though doubt that's a viable option for me. Thanks for the info though!

Can you point us to these cheap Norco non-hotswapping 5-in-3's, and ideally where to buy them? I've searched quite a bit and this is the only reference to non-backplane 5-in-3 I've been able to find :-/ I feel somewhat foolish paying $100 for a hotswapping 5-in-3 when you can get a non-hotswapping 4-in-3 for <$25. A cheap non-hotswapping 5-in-3 would be great.

Thanks, Joe! Helpful as always

Just finished 2 (separate) rounds of preclear on a drive that will replace my parity, and just wanted some eyes more familiar with SMART stats to confirm that these deltas are nothing to be concerned about: 1st preclear 2nd preclear The only ones that seem intuitively concerning to me are the Raw_Read_Error_Rate and Hardware_ECC_Recovered changes. Though this page seems to indicate this may be fine. Thoughts?

Check in your BIOS for settings related to IDE for the SATA chipset. you want to set the "mode" on the chipset to AHCI for best and native SATA performance. The only potentially-relevant setting I could find in my BIOS was for a SATA RAID mode, which some sites say might implicitly enable AHCI; I left it off. However, hdparm -I says NCQ is supported/enabled for these drives, which implies to me that the drives aren't running in legacy IDE mode.

I don't actually have any of that hardware, except the nVidia motherboard. Looks like I have a few extra modules loading / kernel drivers compiled in that I don't need.

After reading all the talk here on the board about 'parity errors', they were on my mind and I simply misspoke; thanks for being extra clear, though. I haven't been able to reproduce these ICRC errors in standalone testing yet as I'm not sure where on the disk they occurred, but... This "MBR preclear error" seems to stem simply from a different implementation of "echo" in my environment. My version of echo wants "\0" preceding octal numbers, and has no idea what I'm talking about when given, for instance, "\252" in the script: root@nickserver:/usr/src/linux# echo -ne "\252" \252root@nickserver:/usr/src/linux# "Step 6" # set MBR signature in last two bytes in MBR # two byte MBR signature echo -ne "\252" | dd bs=1 count=1 seek=511 of=$theDisk echo -ne "\125" | dd bs=1 count=1 seek=510 of=$theDisk The script is expecting out4 = 00170 and out5 = 00085 echo -ne "\252" | dd bs=1 count=1 seek=511 of=/dev/sdc >& /dev/null echo -ne "\125" | dd bs=1 count=1 seek=510 of=/dev/sdc >& /dev/null root@nickserver:~# dd bs=1 count=1 skip=511 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' 00092 root@nickserver:~# dd bs=1 count=1 skip=510 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' 00092 echo -ne "\0252" | dd bs=1 count=1 seek=511 of=/dev/sdc >& /dev/null echo -ne "\0125" | dd bs=1 count=1 seek=510 of=/dev/sdc >& /dev/null root@nickserver:~# dd bs=1 count=1 skip=511 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' #out4 00170 root@nickserver:~# dd bs=1 count=1 skip=510 if=/dev/sdc 2>/dev/null |sum|awk '{print $1}' #out5 00085 I'd like to think that's an accurate statement. On the other hand, it's possible that I know just enough to be a danger to myself ;-) Really though, thanks for the prod to 'go figure it out yourself'! This wasn't an issue that could have reasonably been figured out by anyone without access to my system. These are SATA drives. How would I check to make sure I'm not in IDE emulation mode? A quick bit of googling wasn't conclusive. The preclear script had a single CRC error that I haven't been able to repeat. I think I'm going to go ahead and power cycle and run it again, to see what happens. Though if anyone has other ideas (particularly to try to reproduce the CRC error) I'd be open to trying it, as a 10 hour test cycle is going to be a little frustrating if it keeps failing at the end Thanks again for your help, Joe.

I'm setting up my unRAID (Pro) server for the first time (and running on a full Slackware 13.1 installation). Both of my SATA Samsung 1.5G 154UI drives gave me results similar to this after 10.5 hours: =========================================================================== = unRAID server Pre-Clear disk /dev/sdb = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Temperature: 32C, Elapsed Time: 10:32:36 ============================================================================ == == SORRY: Disk /dev/sdb MBR could NOT be precleared == == out4= 00092 == out5= 00092 ============================================================================ 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000245285 s, 2.1 MB/s 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000700 0000 0000 0000 003f 0000 7af1 aea8 0000 0000720 0000 0000 0000 0000 0000 0000 0000 0000 * 0000760 0000 0000 0000 0000 0000 0000 0000 5c5c 0001000 Each item is "DONE", but it fails with no indication of what the problem is or why, just "could NOT be precleared".... I see this in the syslog, but it seems odd that the parity errors would occur on both SATA drives at the exact same time Dec 14 01:55:48 nickserver kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x580000 action 0x6 Dec 14 01:55:48 nickserver kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x1980000 action 0x6 Dec 14 01:55:48 nickserver kernel: ata4.00: BMDMA stat 0x25 Dec 14 01:55:48 nickserver kernel: ata4: SError: { 10B8B Dispar LinkSeq TrStaTrns } Dec 14 01:55:48 nickserver kernel: ata3.00: BMDMA stat 0x25 Dec 14 01:55:48 nickserver kernel: ata4.00: failed command: WRITE DMA EXT Dec 14 01:55:48 nickserver kernel: ata4.00: cmd 35/00:00:68:53:f8/00:04:10:00:00/e0 tag 0 dma 524288 out Dec 14 01:55:48 nickserver kernel: res 51/84:b3:b5:54:f8/84:02:10:00:00/e0 Emask 0x10 (ATA bus error) Dec 14 01:55:48 nickserver kernel: ata4.00: status: { DRDY ERR } Dec 14 01:55:48 nickserver kernel: ata4.00: error: { ICRC ABRT } Dec 14 01:55:48 nickserver kernel: ata3: SError: { 10B8B Dispar Handshk } Dec 14 01:55:48 nickserver kernel: ata3.00: failed command: WRITE DMA EXT Dec 14 01:55:48 nickserver kernel: ata3.00: cmd 35/00:00:98:df:d2/00:04:0e:00:00/e0 tag 0 dma 524288 out Dec 14 01:55:48 nickserver kernel: res 51/84:61:37:e0:d2/84:03:0e:00:00/e0 Emask 0x10 (ATA bus error) Dec 14 01:55:48 nickserver kernel: ata3.00: status: { DRDY ERR } Dec 14 01:55:48 nickserver kernel: ata3.00: error: { ICRC ABRT } Thoughts? If I saw this in someone else's log, I might think it was due to an insufficient PSU. I don't think that's my issue, though; I've got a 480W Antec power supply running 3 HDDs, a CD/DVD drive, a graphics card, and the motherboard/CPU -- that's it. syslog.txt