CS01-HS

That board is (I believe) limited to 9th and 8th Intel CPUs so if the 5W HBA savings isn't valuable it probably makes sense to go with a newer board and CPU. I don't know enough about them to make recommendations.

How "low power" and how many disks? If you're really "Watt-pinching" and don't mind the older chipset/CPUs: And its bigger mATX brother: https://www.gigabyte.com/us/Motherboard/C246M-WU4-rev-1x#kf Both have 8 SATA on board. A dedicated HBA will add 5W minimum.

FYI when upgrading from Buster to Bullseye I had to update my fstab entry for the 9p mount from: trans=virtio,nofail to trans=virtio,_netdev,nofail

Due to the error above I've run my integrated ASM1062 controller with /sys/class/scsi_host/host*/link_power_management_policy set to max_performance (the default) vs --auto-tune's med_power_with_dipm. After updating to 6.10.0-rc1 a few days ago I tried powertop's med_power_with_dipm again and so far the error hasn't reappeared. Whatever incompatibility appears to be solved. EDIT: I spoke too soon. Under heavy load I saw hard resets again and the (Seagate) drive's Command timeout entry increased by two.

To add further complication behavior seems to depend on the particular USB drive/controller. This script worked (and was necessary) for me for all 6.8.X and 6.9.X versions. I don't know about 6.10 because I've switched from USB to an odroid HC2 (nice little machine.) If I remember right unraid had issues tracking spindown state because my drive (WD Passport) would exit with an error code from hdparm -C /dev/sdX - something about "bad/missing sense" but that indicated it was actually spun down. smartctl worked properly however. To work around it I modified unRAID's sdspin to ignore that particular error and prefer smartctl to hdparm with USB drives. In /boot/config/go I put: # Custom sdspin (to handle substandard USB drive controller) cp /usr/local/sbin/sdspin /usr/local/sbin/sdspin.unraid cp /boot/extras/utilities/sdspin /usr/local/sbin/sdspin chmod 755 /usr/local/sbin/sdspin where /boot/extras/utilities/sdspin was my customized version: #!/bin/bash # spin device up or down or get spinning status # $1 device name # $2 up or down or status # ATA only # hattip to Community Dev @doron RDEVNAME=/dev/${1#'/dev/'} # So that we can be called with either "sdX" or "/dev/sdX" get_device_id () { LABEL="${RDEVNAME:5}" DEVICE_ID=`ls -l /dev/disk/by-id/ | grep -v " wwn-" | grep "${LABEL}$" | rev | cut -d ' ' -f3 | rev` echo "$DEVICE_ID" } smartctl_status () { OUTPUT=$(/usr/sbin/smartctl --nocheck standby -i $RDEVNAME 2>&1) RET=$? # Ignore Bit 1 error (Device open failed) which usually indicates standby [[ $RET == 2 && $(($RET & 2)) == 2 ]] && RET=0 } hdparm () { OUTPUT=$(/usr/sbin/hdparm $1 $RDEVNAME 2>&1) RET=$? # ignore missing sense warning which might be caused by a substandard USB interface if [[ ! "$(get_device_id)" =~ ^usb-.* ]]; then [[ $RET == 0 && ${OUTPUT,,} =~ "bad/missing sense" ]] && RET=1 fi } if [[ "$2" == "up" ]]; then hdparm "-S0" elif [[ "$2" == "down" ]]; then hdparm "-y" else # use smartctl (instead of hdparm) for USB drives if [[ "$(get_device_id)" =~ ^usb-.* ]]; then smartctl_status else hdparm "-C" fi [[ $RET == 0 && ${OUTPUT,,} =~ "standby" ]] && RET=2 fi Very hacky.

You can even include unraid notifications (in addition to the "echo" printouts.) Notices ("normal") appear in green: /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "Backup Critical Files" -d "Backup complete" -i "normal" and alerts in red: /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Error" -s "Backup Critical Files" -d "Backup error" -i "alert"

If Windows backs up on the same day every week you could add a user script to unRAID that runs later or the next day. I just wrote one similar for another device. You may have to tweak it slightly for unraid/your use case. Carefully test it because it calls rm and you don't want to accidentally wipe your array (or at least comment out the rm line until you're sure it works.) #!/bin/bash # # Backup critical files # ## Options # Number of backups to keep NUM_TO_KEEP=6 # directory to be backed up BACKUP_SOURCE="/mnt/hdd/share/unraid" # directory to store backups BACKUP_DEST="/mnt/hdd/share/backup" # Begin backup dest_file="${BACKUP_DEST}/unraid-$(date '+%Y-%m-%d')" echo "Archiving critical files to: ${dest_file}.tar.gz" tar -czf ${dest_file}.tar.gz ${BACKUP_SOURCE} if [[ $? != 0 ]]; then # Alert echo "Critical Backup Archiving FAILED" exit 1 fi # make it readable by all chmod a+r ${dest_file}.tar.gz # Clear out all but X most recent (cd ${BACKUP_DEST}/ && rm `ls -t *.tar.gz | awk "NR>$NUM_TO_KEEP"`) 2>/dev/null # Alert succes echo "Critical Backup Archiving Completed" exit 0

Thanks, I see this command in help: /usr/local/sbin/rc.unassigned spindown devX I wish I'd known about it earlier, still the script worked well for me in 6.8 and 6.9. jinlife: I'd say disable the script for now, unmount the drive, run the command above where "devX is the device name in the UD page. If the device name is 'Dev 1', then use dev1 as the device to spin down."

You say the USB HDD spins up every hour, so it must be spinning down. Is it spinning down on its own or is my script spinning it down? You could try disabling the USB HDD's internal power management: Find the disk's ID with: find /dev/disk/by-id/ ! -name '*-part1' The line for your USB disk will look like: /dev/disk/by-id/usb-XXXXXX Take that and disable power management with the command: /usr/sbin/smartctl -s apm,off /dev/disk/by-id/usb-XXXXXX If that fixes it add the command exactly the way you ran it to your /boot/config/go because reboot resets it.

If I remember right you need the intel-gpu-telegraf docker to collect the stats in telegraf. EDIT: Now that I think about it this plugin may not be necessary for stats collection, just the docker. Not sure, sorry it's been a while since I set it up. EDIT 2: Ha, apparently I had my plugins confused. It's the Intel GPU TOP plugin that works with the docker to collect stats.

I think you can disable UI Automatic Refresh in the plugin's settings to mostly solve it. Dashboard reporting's less useful than stats to track usage, e.g. through Grafana.

If you use syslog server you can add them to a blocklist. Here's an excerpt from my go file: # Suppress time capsule cifs errors echo ":msg,contains,\"bogus file nlink value\" stop" >> /etc/rsyslog.d/01-blocklist.conf echo ":msg,contains,\"cifs_all_info_to_fattr\" stop" >> /etc/rsyslog.d/01-blocklist.conf /etc/rc.d/rc.rsyslogd restart

I believe I found the culprit - Fix Common Problems. And here's the fix (I'm surprised it's not the default):

I have not. Maybe when I get more time. Could it be a difference in kernels? Maybe 6.10 will fix it.

Very nice. I keep my fingers crossed for a W580 m-itx. Yes. No difference as far as I can tell: root@NAS:~# dmesg | grep -i aspm [ 0.000000] Command line: BOOT_IMAGE=/bzimage initrd=/bzroot mitigations=off intel_iommu=on,igfx_off pcie_aspm=force [ 0.103794] Kernel command line: BOOT_IMAGE=/bzimage initrd=/bzroot mitigations=off intel_iommu=on,igfx_off pcie_aspm=force [ 0.103948] PCIe ASPM is forcibly enabled [ 0.454763] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] root@NAS:~# lspci -vv | grep ASPM LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 <4us ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM not supported ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- LnkCap: Port #5, Speed 5GT/s, Width x1, ASPM not supported ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ LnkCap: Port #6, Speed 5GT/s, Width x1, ASPM not supported ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- pcilib: sysfs_read_vpd: read failed: Input/output error LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s, Exit Latency L0s <64ns ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM not supported ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ root@NAS:~#

I believe you have (or had) a j5005? With my j5005 I have the same problem as the German user. ASPM is enabled in the BIOS and apparently supported: root@NAS:~# dmesg | grep -i aspm [ 0.454584] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3] But disabled on all devices: root@NAS:~# lspci -vv | grep 'ASPM.*abled' LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ pcilib: sysfs_read_vpd: read failed: Input/output error LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+

From the XML view of my VM it appears the FD file goes in: /etc/libvirt/qemu/nvram/ Which is one level down from the XML file in: /etc/libvirt/qemu/

Same on my j5005 (UHD 605) I reverted to the last tag: then restored appdata and the template (/boot/config/plugins/dockerMan/templates-user/my-HandBrake.xml) from backup and all is well.

Intel QSV:

Yes. You can see it working in second graph (Handbrake conversion.) The GPU's utilized but at a much lower level vs Emby. Seems this problem's unique to me but will post if I make any progress. Note: I have all video encoding filters disabled in Handbrake settings.

Interesting. My conversions are noticeably faster with hardware encoding than pure CPU so it must be doing something. Here are graphs of GPU utilization (dashed line) courtesy of gpu-monitor. Emby transcoding: Handbrake hardware conversion: Both using the intel quicksync driver and assigned to 3 CPUs. I wonder what accounts for the difference.

Slightly off-topic but does anyone know why Handbrake doesn't do hardware decoding? When I convert h264 -> h265 using hardware encoding (thanks Djoss) I see low iGPU utilization and high CPU. Contrast with Emby/ffmpeg h265 -> h264 which has high GPU utilization and low CPU. Seems like such an obvious oversight I wonder if there's something I'm missing.

Did you ever figure out what was causing this? I'm also seeing it.

Looks like it backs up all of them. See log from a recent run (core-backup/domains is the destination directory) 2021-04-27 10:41:02 information: Debian is shut off. vm desired state is shut off. can_backup_vm set to y. 2021-04-27 10:41:02 information: actually_copy_files is 1. 2021-04-27 10:41:02 information: can_backup_vm flag is y. starting backup of Debian configuration, nvram, and vdisk(s). sending incremental file list Debian.xml sent 7,343 bytes received 35 bytes 14,756.00 bytes/sec total size is 7,237 speedup is 0.98 2021-04-27 10:41:02 information: copy of Debian.xml to /mnt/user/core-backup/domains/Debian/20210427_1040_Debian.xml complete. sending incremental file list 55c212-015b-6fc0-dada-cba0018034_VARS-pure-efi.fd sent 131,246 bytes received 35 bytes 262,562.00 bytes/sec total size is 131,072 speedup is 1.00 2021-04-27 10:41:02 information: copy of /etc/libvirt/qemu/nvram/55c212-015b-6fc0-dada-cb6ca0018034_VARS-pure-efi.fd to /mnt/user/core-backup/domains/Debian/20210427_1040_55c21fa2-015b-6fc0-dada-cba0018034_VARS-pure-efi.fd complete. '/mnt/cache/domains/Debian/vdisk1.img' -> '/mnt/user/core-backup/domains/Debian/20210427_1040_vdisk1.img' 2021-04-27 10:42:19 information: copy of /mnt/cache/domains/Debian/vdisk1.img to /mnt/user/core-backup/domains/Debian/20210427_1040_vdisk1.img complete. 2021-04-27 10:42:19 information: backup of /mnt/cache/domains/Debian/vdisk1.img vdisk to /mnt/user/core-backup/domains/Debian/20210427_1040_vdisk1.img complete. 2021-04-27 10:42:19 information: extension for /mnt/user/isos/debian-10.3.0-amd64-netinst.iso on Debian was found in vdisks_extensions_to_skip. skipping disk. 2021-04-27 10:42:19 information: the extensions of the vdisks that were backed up are img. 2021-04-27 10:42:19 information: vm_state is shut off. vm_original_state is running. starting Debian. Domain Debian started 2021-04-27 10:42:20 information: backup of Debian to /mnt/user/core-backup/domains/Debian completed.

I had a strange problem where maybe every fifth boot my Mojave VM wouldn't have a network connection (using e1000-82545em.) The adapter (Realtek RTL8111H) was detected but no connection. I fixed it by manually configuring the adapter in the VM. Dozens of boots so far and it hasn't happened again. Hope that's helpful.