xtrap225

Members
  • Posts

    38
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xtrap225's Achievements

Rookie

Rookie (2/14)

1

Reputation

1

Community Answers

  1. i want to add some tangential information for others that are reading this thread. i reinstalled the dynamix file integrity plugin again and it slowed my parity right back down. its running blake3 btw. my cpu is Intel® Xeon W-2235 so it has the proper avx extensions for it. so i excluded the time-machine backup shares from its check, which is the only place i ever had so-called bitrot, but i am sure those were false positives. as i have used them for restores more than a few times and never had any issues. i am unsure if you are not supposed to check time-machine shares anyway or not, but i don't think it works properly with those. if someone else thinks otherwise and has the same issue, you may wish to go over to the support for that plugin and report it. but once i excluded those, my parity is running ~150MBps on the newer drives and ~115MBps on the older drives. it has increased my average system load to around 4, but that is just while it catches up i assume. also i am re-enabling spectre mitigations and removing that plugin. (mainly cause i didn't see any difference with them enabled and the newer 6.11.0 has even more mitigations built in) and i will updates to 6.11.0 from 6.10.3 once this parity check i haven't gotten in so long is done. however i am now a little concerned, yesterday when i ran the upgrade assistance it said i was all good to go, now something has changed and it says nerdpack and devpack aren't compatible and should be uninstalled. so i might need to wait for an update on those, assuming that happens. i am pretty sure i need those, so i don't want to just rip them out. i am lucky i didn't get the upgrade notification while i was doing my maintenance yesterday cause i probably would have just done it, and had major issues. i hope those packs (nerd & dev), aren't being abandoned and that they get an update soon that makes them compatible. so i don't want to reboot again until parity is done, and its about 50% done now, which is sooooooo much faster than it was running.
  2. i think i got it. all previously posts were with docker disabled. i have removed the dynamix file integrity plugin, and started up docker. so far so good. load average is floating around ~2.4 to ~3 ,, ah gone down to 2.2 and lower ~1.71 so that is ~12 dockers running and the parity check so thank you for your help but i believe all is well again, i guess that plugin is broken or defunct now, or not and i just need to rework it better if its still useful.
  3. i know i said i would wait but with just SMB and VM service enable (none actually on), after 15min of parity check i really thought it would be something to do with docker i stopped automatic timemachine backups cause i found that had kicked off and cancelled it. i stopped my sonarr, radarr, and lidarr services on another machine which could cause network traffic to the unraid server's array. it didn't help my load average has jumped back up to ~26 and possibly rising. dell-pc-diagnostics-20220924-1654.zip
  4. disabled spectre (cpu) mitigation and kept all three major services off(SMB,VMS,Docker) and started array in normal mode load average is ~2 and parity check looks good. i am going to start enabling things again, and keep testing along the way, i won't upload anything else unless you ask me to. or if i figure it out. dell-pc-diagnostics-20220924-1616.zip
  5. same as before . array started normal, no docker service, no vm service, this time also stopped SMB service let it run a little longer but load average is ~2.72 dell-pc-diagnostics-20220924-1558.zip
  6. load average after reboot, nothing running array stopped = 0.15 to 0.3 maint-mode parity started normally = 1.88 also parity looks good. array started normal (SMB still enabled), docker service disabled, vm service disabled. = ~3.02 downloaded the diag after it was running like this for a little bit. gonna stop it again and disable SMB and start it and see what happens, while eagerly await your replydell-pc-diagnostics-20220924-1536.zip. dell-pc-diagnostics-20220924-1536.zip
  7. okay i stopped the docker service and no significant change still over 30 load average. stopped the vm service (even though there only one vm and it wasn't on) same, still over 30 load average. i not just paused but cancelled the currently running parity and still no change. turned off auto start the array in prep for reboot. when it reboot and it comes back, should i start in maint-mode? or just leave off those services and start the array normal and run a parity for a while before uploading? how long is a while? did i miss turning off any other services? like smb or whatever(i guess i would have to stop the array so it might as be after the reboot if you want it stopped) ? i checked and no time-machine backups are running (really there is only one anyway, on the laptop i am writing this from.
  8. i will do that but i can't right now, i did however pause and then resume the parity here is a screenshot of the htop running sorted heavy cpu to the top, doesn't seem too bad.
  9. i have recently migrated to a new server and added two new parity drives they are 12TB WD RED plus nas. they are internal to the server on the 'Intel Corporation C600/X79 series chipset SATA RAID Controller' the rest of the array besides the nvme cache and one for passthrough to a vm, which was off during the time the diag was taken. anyway the rest of the array is 22 disks via a 'Broadcom / LSI SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)' which is connected to a NetApp DS4246, with IOM6 modules, (just using one). the drives are all seagate 3TB ST3000NM0033 except, 3 are 8TB WD RED NAS WD80EFAX drives. previously about a month ago after switching to this server already i was getting ... Parity-Check 2022-07-06, 00:28:08 8 TB 21 hr, 28 min, 7 sec 103.5 MB/s OK 0 but that was before adding the new 12 TB parity on another internal controller. here is the parity sync for that. Parity-Sync 2022-08-05, 08:18:10 12 TB 1 day, 6 hr, 30 min, 13 sec 109.3 MB/s OK 0 but since then i have had super slow parity can't finish it cause it will take half a year. Total size:12 TB Elapsed time: 18 hours, 44 minutes Current position: 126 GB (1.0 %) Estimated speed: 1.2 MB/sec Estimated finish: 115 days, 7 hours, 58 minutes Sync errors corrected: 0 i thought maybe my vm was slowing it down so i turned that off, which crashes the whole system but thats a different issue. and since then i have not turned on the vm. how can i troubleshoot my slow parity what should i look at. i can't find any issues with the drives or their speeds or their controllers or speeds. not sure where to look or test next. any help would be appreciated. dell-pc-diagnostics-20220924-1019.zip
  10. does anyone know how to configure bdd.conf (i assume) to work behind swag ( the new letsencrypt/nginx docker from linuxserver.io). the settings i am putting into the bdd.conf don't seem to stay, after i restart the barracuda docker?
  11. unfortunately no, i have it set it disabled. i did find my serial to usb cable but i haven't had time to see if it works on unraid to telnet into iom6
  12. so ever since i added the following to my /boot/config/go file to enable hardware transcoding to plex. #Setup drivers for hardware transcoding in Plex modprobe i915 chown -R nobody:users /dev/dri chmod -R 777 /dev/dri here is the lines im seeing in the syslog Sep 22 23:25:22 WORK-PC kernel: [drm] GPU HANG: ecode 7:6:0xacdfbffe, reason: hang on vecs0, action: reset Sep 22 23:25:22 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 ... Sep 23 01:14:03 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:11 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:19 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:27 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:35 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:43 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:51 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:14:59 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 Sep 23 01:15:07 WORK-PC kernel: i915 0000:00:02.0: Resetting chip for hang on vecs0 ... Sep 23 01:45:27 WORK-PC kernel: Plex Media Scan[28422]: segfault at b0 ip 000014cfbfe01097 sp 000014cfb19fe000 error 4 in libcrypto.so.1.0.0[14cfbfcf0000+204000] Sep 23 01:45:27 WORK-PC kernel: Code: 8b 4f 1c 31 d2 4c 89 e0 48 f7 f1 49 8b 07 48 63 ca 4c 8b 2c c8 4d 85 ed 74 37 49 8b 6f 08 48 8d 1c c8 90 49 ff 87 a0 00 00 00 <4d> 39 65 10 75 11 49 ff 47 68 49 8b 7d 00 4c 89 f6 ff d5 85 c0 74 when googling the error i found some people said that if you add some parameters to the kernel you can fix the issue. https://forum.manjaro.org/t/i915-gpu-hang-solved/37200/13 Solved! Adding these parameters to the kernel is fixed: i915.modeset=1 i915.enable_rc6=1 i915.enable_fbc=1 i915.enable_guc_loading=1 i915.enable_guc_submission=1 i915.enable_huc=1 i915.enable_psr=1 i915.disable_power_well=0 i915.semaphores=1 It works in version 4.14 and 4.15 on the other hand hoopster said in this thread that the Intel i5-9500 is not supported in kernel 4.19, but mine is an older cpu. Linux WORK-PC 4.19.56-Unraid #1 SMP Tue Jun 25 10:19:34 PDT 2019 x86_64 Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz GenuineIntel GNU/Linux Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz here is some more info if anyone thinks its relevant root@WORK-PC:~# systool -m i915 -av Module = "i915" Attributes: coresize = "1261568" initsize = "0" initstate = "live" refcnt = "0" taint = "" uevent = <store method only> Parameters: alpha_support = "N" disable_display = "N" disable_power_well = "1" dmc_firmware_path = "(null)" edp_vswing = "0" enable_dc = "-1" enable_dp_mst = "Y" enable_dpcd_backlight= "N" enable_fbc = "0" enable_guc = "0" enable_gvt = "N" enable_hangcheck = "Y" enable_ips = "1" enable_ppgtt = "1" enable_psr = "-1" error_capture = "Y" fastboot = "N" force_reset_modeset_test= "N" guc_firmware_path = "(null)" guc_log_level = "0" huc_firmware_path = "(null)" invert_brightness = "0" load_detect_test = "N" lvds_channel_mode = "0" mmio_debug = "0" modeset = "-1" nuclear_pageflip = "N" panel_use_ssc = "-1" prefault_disable = "N" reset = "2" vbt_firmware = "(null)" vbt_sdvo_panel_type = "-1" verbose_state_checks= "Y" Sections: .altinstr_aux = "0xffffffffa07a5b83" .altinstr_replacement= "0xffffffffa07a5638" .altinstructions = "0xffffffffa07db727" .bss = "0xffffffffa080ddc0" .data..read_mostly = "0xffffffffa080da40" .data.once = "0xffffffffa080d9d0" .data = "0xffffffffa0809020" .exit.text = "0xffffffffa07a5bdd" .fixup = "0xffffffffa07a5bf4" .gnu.linkonce.this_module= "0xffffffffa080dac0" .init.text = "0xffffffffa082f000" .note.Linux = "0xffffffffa07a6024" .note.gnu.build-id = "0xffffffffa07a6000" .orc_unwind = "0xffffffffa07edebc" .orc_unwind_ip = "0xffffffffa07dd1dc" .parainstructions = "0xffffffffa07dc260" .rodata = "0xffffffffa07a6080" .rodata.str1.1 = "0xffffffffa07bc59c" .smp_locks = "0xffffffffa07dbc98" .strtab = "0xffffffffa084c758" .symtab = "0xffffffffa0830000" .text..refcount = "0xffffffffa07a57d1" .text = "0xffffffffa06fa000" .text.unlikely = "0xffffffffa07a5c71" __bug_table = "0xffffffffa080ad90" __ex_table = "0xffffffffa080720c" __jump_table = "0xffffffffa0809000" __ksymtab_gpl = "0xffffffffa07a6040" __ksymtab_strings = "0xffffffffa0807fd8" __param = "0xffffffffa0807ab0" work-pc-diagnostics-20190923-0557.zip
  13. i just want to bottom line this for anyone who jumped into their setup like me, because they wanted a bunch of storage on the cheap. i own a NetApp DS4246, with all 3TB sata drives in it. using a Dell LSI SAS 9202-16e 6Gb/s SAS Host Bus Adapter to plug it into a pretty generic Lenovo desktop computer w/ 32GB of ram and an Intel i5-4570. anyway, the big mistake i made for years while running UnRaid was to think that i was supposed to use SAS or SCSI settings on the SMART setup because of the NetApp and/or the HBA, that is NOT correct. pretty obviously when you think about it, SMART is internal to the drives and the drives are SATA so set your SMART up as SATA and it will work perfectly. No extra setup required. (i just thought i would add this final note for anyone reading this thread).
  14. put that in my go file and started another smartctl long test on a different drive that i have less faith in while witing for my preclear to finish on sdp. sdp and sdm (the one i am running long test on now) are the only drives that when the system is rebooted lose their write-cache setting, and i have to use hdparm -W1 /dev/sdm and sdp to turn it back on. ( i have also now added that to the go file). i am only making note of these things now so that people can benefit form this experience and i will have the commands noted in this thread. root@WORK-PC:~# smartctl -d sat -t long -C /dev/sdm smartctl 7.0 2018-12-30 r4883 [x86_64-linux-4.19.56-Unraid] (local build) Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Extended self-test routine immediately in captive mode". Drive command "Execute SMART Extended self-test routine immediately in captive mode" successful. Testing has begun. Please wait 369 minutes for test to complete. Test will complete after Mon Sep 9 23:29:45 2019 and here is a copy of my /boot/config/go file. root@WORK-PC:~# cat /boot/config/go #Setup smartd.conf mv /etc/smartd.conf /etc/smartd.conf.backup cp -p /boot/smartd.conf.bak /etc/smartd.conf chmod 644 /etc/smartd.conf chmod 755 /etc/rc.d/rc.smartd /etc/rc.d/rc.smartd start #enable write cache on sdm and sdp hdparm -W1 /dev/sdm hdparm -W1 /dev/sdp #Setup drivers for hardware transcoding in Plex modprobe i915 chown -R nobody:users /dev/dri chmod -R 777 /dev/dri #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & and for anyone with a netapp here is the /etc/smartd.conf i will be using. root@WORK-PC:~# cat /etc/smartd.conf #DEVICESCAN # Monitor LSI's disk SMART through SCSI generic /dev/sdb -d sat -a -s L/../../3/02 /dev/sdc -d sat -a -s L/../../3/03 /dev/sdd -d sat -a -s L/../../3/04 /dev/sde -d sat -a -s L/../../3/05 /dev/sdf -d sat -a -s L/../../3/06 /dev/sdg -d sat -a -s L/../../3/07 /dev/sdh -d sat -a -s L/../../3/08 /dev/sdi -d sat -a -s L/../../3/09 /dev/sdj -d sat -a -s L/../../3/10 /dev/sdk -d sat -a -s L/../../3/11 /dev/sdl -d sat -a -s L/../../3/12 /dev/sdm -d sat -a -s L/../../3/13 /dev/sdn -d sat -a -s L/../../3/14 /dev/sdo -d sat -a -s L/../../3/15 /dev/sdp -d sat -a -s L/../../3/16 /dev/sdq -d sat -a -s L/../../3/17 /dev/sdr -d sat -a -s L/../../3/18 /dev/sds -d sat -a -s L/../../3/19 /dev/sdt -d sat -a -s L/../../3/20 /dev/sdu -d sat -a -s L/../../3/21 /dev/sdv -d sat -a -s L/../../3/22 /dev/sdw -d sat -a -s L/../../3/23 /dev/sdx -d sat -a -s L/../../3/24 /dev/sdy -d sat -a -s L/../../3/25 /dev/sdz -d sat -a -s L/../../3/26 here is the /var/log/syslog of the smartd loading up with the new config root@WORK-PC:~# less /var/log/syslog Sep 9 17:12:01 WORK-PC smartd[9481]: Device: /dev/sdu [SAT], not found in smartd database. Sep 9 17:12:01 WORK-PC smartd[9481]: Device: /dev/sdu [SAT], not capable of SMART Health Status check Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdu [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdv [SAT], opened Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdv [SAT], SEAGATE ST3000NM0033, S/N:Z1Y1T5V8, WWN:5-000c50-0675c7981, FW:NS00, 3.00 TB Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdv [SAT], not found in smartd database. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdv [SAT], not capable of SMART Health Status check Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdv [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdw [SAT], opened Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdw [SAT], SEAGATE ST3000NM0033, S/N:Z1Y1X2MN, WWN:5-000c50-0675c76b3, FW:NS00, 3.00 TB Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdw [SAT], not found in smartd database. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdw [SAT], not capable of SMART Health Status check Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdw [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdx [SAT], opened Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdx [SAT], SEAGATE ST3000NM0033, S/N:Z1Y1X2JX, WWN:5-000c50-0675c876f, FW:NS00, 3.00 TB Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdx [SAT], not found in smartd database. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdx [SAT], not capable of SMART Health Status check Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdx [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdy [SAT], opened Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdy [SAT], SEAGATE ST3000NM0033, S/N:Z1Y1X2NR, WWN:5-000c50-0675c859a, FW:NS00, 3.00 TB Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdy [SAT], not found in smartd database. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdy [SAT], not capable of SMART Health Status check Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdy [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdz [SAT], opened Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdz [SAT], SEAGATE ST3000NM0033, S/N:Z1Y1T69A, WWN:5-000c50-0675c6f7d, FW:NS00, 3.00 TB Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdz [SAT], not found in smartd database. Sep 9 17:12:02 WORK-PC smartd[9481]: Device: /dev/sdz [SAT], not capable of SMART Health Status check Sep 9 17:12:03 WORK-PC smartd[9481]: Device: /dev/sdz [SAT], is SMART capable. Adding to "monitor" list. Sep 9 17:12:03 WORK-PC smartd[9481]: Monitoring 25 ATA/SATA, 0 SCSI/SAS and 0 NVMe devices Sep 9 17:12:04 WORK-PC smartd[9481]: Device: /dev/sdm [SAT], previous self-test was interrupted by the host with a reset Sep 9 17:12:05 WORK-PC smartd[9481]: Device: /dev/sdp [SAT], previous self-test was interrupted by the host with a reset Sep 9 17:12:06 WORK-PC smartd[10307]: smartd has fork()ed into background mode. New PID=10307. Sep 9 17:12:06 WORK-PC smartd[10307]: file /run/smartd.pid written containing PID 10307
  15. now if i figure out how to properly modify the smartd.conf to properly detect the drives with the -d sat instead of doing DEVICESCAN which is putting in scsi maybe i can have a better unraid smart experience in general. not sure if i should use /dev/sdp or the equivalent /dev/sgX but assuming ill stick with 'sd' here is what my /etc/smartd.conf would look like. #DEVICESCAN # Monitor LSI's disk SMART through SCSI generic /dev/sdb -d sat -a -s L/../../3/02 /dev/sdc -d sat -a -s L/../../3/03 /dev/sdd -d sat -a -s L/../../3/04 /dev/sde -d sat -a -s L/../../3/05 /dev/sdf -d sat -a -s L/../../3/06 /dev/sdg -d sat -a -s L/../../3/07 /dev/sdh -d sat -a -s L/../../3/08 /dev/sdi -d sat -a -s L/../../3/09 /dev/sdj -d sat -a -s L/../../3/10 /dev/sdk -d sat -a -s L/../../3/11 /dev/sdl -d sat -a -s L/../../3/12 /dev/sdm -d sat -a -s L/../../3/13 /dev/sdn -d sat -a -s L/../../3/14 /dev/sdo -d sat -a -s L/../../3/15 /dev/sdp -d sat -a -s L/../../3/16 /dev/sdq -d sat -a -s L/../../3/17 /dev/sdr -d sat -a -s L/../../3/18 /dev/sds -d sat -a -s L/../../3/19 /dev/sdt -d sat -a -s L/../../3/20 /dev/sdu -d sat -a -s L/../../3/21 /dev/sdv -d sat -a -s L/../../3/22 /dev/sdw -d sat -a -s L/../../3/23 /dev/sdx -d sat -a -s L/../../3/24 /dev/sdy -d sat -a -s L/../../3/25 /dev/sdz -d sat -a -s L/../../3/26