Spies

What's the comparative speed when writing to a relatively full SMR disk in unraid?

I've used unraid for a long time but recently have a faster internet connection 80/20, my desktop computer is able to take full advantage of the 80mbps but my unraid dockers never seem to manage more than around 60mbps even through sabnzb which uses multiple threads. My local network speed when testing with the speedtest docker is fine, I have even tried changing unraids MTU to 1492 to match my connection (pppoe) but it hasn't made a difference. Any suggestions if there are any Linux specific tweaks I need to do?

Sounds normal to be honest, Plex races to fill the buffer when a stream is started so the CPU will initially hit 100%

Seems to have sorted the error in the log but has it just suppressed it or actual fixed the issue?

Still occuring on 6.8 rc7 Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2b8e000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2b16000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2598000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2b18000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2bbf000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f93a0000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fca48000 flags=0x0000] Dec 5 00:00:36 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f4914000 flags=0x0000] Dec 5 00:00:39 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2bb0000 flags=0x0000] Dec 5 00:00:39 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d1dc0000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000ffac0000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000f45e1000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d21c3000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000fc510000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000f48fc000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d261f000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d254c000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d2622000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d29e0000 flags=0x0000] Dec 5 00:00:39 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d2622000 flags=0x0000] Dec 5 00:00:49 Tower kernel: amd_iommu_report_page_fault: 288 callbacks suppressed Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f8eb8000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f9449000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d250b000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2618000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000fb518000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f462e000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000ffbf2000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2b88000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000d2b89000 flags=0x0000] Dec 5 00:00:49 Tower kernel: nvme 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0000 address=0x00000000f8862000 flags=0x0000] Dec 5 00:00:49 Tower kernel: amd_iommu_report_page_fault: 278 callbacks suppressed Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d2b69000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000fb67f000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d2b4a000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d2b86000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d29eb000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000d17a7000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000fcaf7000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000f92de000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000ffd95000 flags=0x0000] Dec 5 00:00:49 Tower kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0000 address=0x00000000ff9b7000 flags=0x0000] Dec 5 00:00:53 Tower root: /etc/libvirt: 920.2 MiB (964935680 bytes) trimmed on /dev/loop3 Dec 5 00:00:53 Tower root: /var/lib/docker: 12.8 GiB (13728591872 bytes) trimmed on /dev/loop2 Dec 5 00:00:53 Tower root: /mnt/cache: 232 GiB (249063817216 bytes) trimmed on /dev/nvme0n1p1

Any further thoughts on this? Disabling IOMMU suppresses the error in the system log, I have upgraded BIOS but still have the issue with IOMMU enabled, going to try 6.8 rc7 when it eventually downloads...

Updated BIOS but still receiving errors. Dec 3 14:27:50 Tower kernel: pcieport 0000:00:03.1: AER: Multiple Corrected error received: 0000:00:00.0 Dec 3 14:27:50 Tower kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 3 14:27:50 Tower kernel: pcieport 0000:00:03.1: device [1022:1453] error status/mask=00000040/00006000

Just looking through my log and noticed this had appeared once since disabling IOMMU in BIOS. Dec 2 19:54:01 Tower kernel: pcieport 0000:00:03.1: AER: Multiple Corrected error received: 0000:00:00.0 Dec 2 19:54:01 Tower kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Dec 2 19:54:01 Tower kernel: pcieport 0000:00:03.1: device [1022:1453] error status/mask=00000040/00006000 Dec 2 19:54:01 Tower kernel: pcieport 0000:00:03.1: [ 6] BadTLP Is this anything to be concerned about? 1022:1453 refers to PCIe GPP Bridge.

https://www.google.com/amp/s/www.techrepublic.com/google-amp/blog/data-center/how-sas-near-line-nl-sas-and-sata-disks-compare/ But admittedly for what we use unraid for, completely unnecessary. Send me 3x 3TB SATA and I'll gladly send you these SAS drives 😂

It's my understanding that SAS drives have better fault tolerance and can correct on the fly, much like ECC memory. My case is that they were pulled from enterprise kit and they are 3TB drives, so I'm not just going to bin them 😉

I must add, this doesn't seem to work for me, on typing the command sg_start --stop /dev/sdg I get the following in the log Dec 2 15:55:31 Tower kernel: sd 13:0:2:0: [sdg] Spinning up disk... Dec 2 15:55:42 Tower kernel: ...........ready Dec 2 15:55:42 Tower kernel: sdg: sdg1

I'm running Version 1804 on my B450 motherboard, which is several version behind the latest, should I update or leave things as they are? Everything appears to be working aside from an issue with IOMMU io_page_fault which I think I have solved by disabling IOMMU in the BIOS.

Could use this in userscripts to automatically spin them down https://gist.github.com/viljoviitanen/4570091

Maybe related to this https://bugzilla.kernel.org/show_bug.cgi?id=202665 Can the kernel patch be applied to the next unraid build?

I didn't have this issue on my previous system, it ran at midnight and the log reported how many bytes were trimmed. Does this mean trim isn't working at all? How can I fix it? tower-diagnostics-20191201-1937.zip

It's happened again this morning at 4:41am, is there a crontab that runs at that time? The cfg file has the following SERVICE="disable" UPSCABLE="usb" CUSTOMUPSCABLE="" UPSTYPE="usb" DEVICE="" BATTERYLEVEL="10" MINUTES="10" TIMEOUT="0" KILLUPS="no"

I've toggled it in the GUI, the cfg file does say SERVICE="disable" however I didn't check it before I toggled. Where does it store the UPS information because when the Daemon is enabled, it populated with the past info?

I used to have a UPS in my server but no longer do, once a week I'm getting an alert that the server has lost communication with the UPS even though the UPS Daemon is set to No in the settings page. On the same settings page it states that it's Running in the top right. Any suggestions on how to fix this besides plugging a UPS back in? tower-diagnostics-20191124-0956.zip

How do I purge the log file this plugin creates?

Perfect, thank you.

Since the last update, when clicking which season you want, nothing is happening. Is it just me? Edit: had to go back to v3.0.4817-ls38 to get it working again, has there been a significant change to the database at some point? Edit2: tried going to v3.0.4880-ls38 and it's broken again, are there any steps between 4817 and build 4880?

Nearly 4 days, I manually rebooted to update unraid.

I don't have it plugged into anything I can use to monitor power, but based on my household usage, I would estimate about 40-60 watts with no HDDs spun up.

I haven't had any issues, I didn't disable C-states but did change Power Supply Idle control to typical current idle instead of auto.

OK, that's a shame.