RWDai

Thank you for mentioning the bug post, it seems to be the same issue I encountered. The command echo 3 > /proc/sys/vm/drop_caches appears to work for me. Process flow: iostat showed that sda (the boot drive) was near 100% utilization, about 98%. Using inotifywait --timefmt %c --format '%T %_e %w %f' -mr /boot, I observed a large number of ACCESS logs for /boot/bzfirmware, and the speed was very high. After running the drop_caches command, the sda utilization dropped to around 1%, and the ACCESS logs in inotifywait for bzfirmware significantly reduced. The load also slightly decreased. By the way, I have 32GB of RAM, with 13GB used by ZFS, 8GB by virtual machines, and some space taken by Docker. Before executing the command, the free -h command showed about 3.3GB free. After running it, around 4.8GB of free memory was available. A few minutes later, the free memory dropped back to around 3.5GB. I hope this helps with the investigation! If you need any additional information, feel free to contact me. I should be able to reproduce this in a few days.

I have the same problem where the boot disk often has high IO, causing me to not be able to connect to SSH or open GUI. I have found several similar problem posts in the forum, but none of them have provided a solution. One of them said it was solved by adding memory, but at least it's not suitable for me. I already have 32GB of memory. Based on my observation, it is highly likely that the occurrence of high IO on the boot disk is also due to a certain disk being high IO. By the way, my system version is 6.12.9. (Why haven't I upgraded to version 6.12.14? Because after upgrading to 6.12.14, the system will lose contact directly after a few hours, suspected to be a kernel crash.)

The Realtek RTL8125 network card is used in conjunction with the network card driver, and there may be some issues with the default driver of unraid. As long as the 8125 driver is installed, this problem will be solved

I downgraded to version 6.12.9, and it has been running stably for 2 days now. I've given up on upgrading to version 6.12.13

thank you，but this is not the main issue

你就touch一下原贴里的文件名称试就可以了，不需要用种子磁力。但是这个是6.12.9的版本 不清楚新版本是否还有这个问题

I will try some of the methods here, which may take several days. By the way, this random loss of connection must occur within a day. It has occurred three or four times now, with different durations. Also, if there is anything valuable in my diagnostic file that could cause the loss of connection, please let me know.

This diagnosis was generated about 12 minutes after the last forced restart after the loss of connection, and may not contain any useful information

Hello everyone, After upgrading from Unraid 6.12.9 to 6.12.13, I’ve been experiencing random disconnects where my server becomes unreachable. I’ve set up a syslog server to capture logs, but it hasn’t recorded anything unusual during the incidents. Nov 21 10:21:58 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 10:21:58 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 10:21:58 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 10:21:58 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 10:26:21 AIO kernel: pcieport 0000:00:01.1: AER: Multiple Corrected error message received from 0000:02:00.0 Nov 21 10:26:21 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 10:26:21 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 10:26:21 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 10:27:22 AIO kernel: pcieport 0000:00:01.1: AER: Multiple Corrected error message received from 0000:02:00.0 Nov 21 10:27:22 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 10:27:22 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 10:27:22 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 10:27:36 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 10:27:36 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 10:27:36 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 10:27:36 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 10:38:55 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 10:38:55 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 10:38:55 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 10:38:55 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 11:04:30 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 11:04:30 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 11:04:30 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Nov 21 11:10:48 AIO kernel: pcieport 0000:00:01.1: AER: Corrected error message received from 0000:02:00.0 Nov 21 11:10:48 AIO kernel: nvme 0000:02:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Nov 21 11:10:48 AIO kernel: nvme 0000:02:00.0: device [15b7:5019] error status/mask=00000001/0000e000 Nov 21 11:10:48 AIO kernel: nvme 0000:02:00.0: [ 0] RxErr Part of logs To further diagnose the issue, I wrote a script to ping my gateway (192.168.31.1) at regular intervals. Below are the logs from the script. The disconnect seems to have occurred around 11:20 AM: 2024/11/21 11:18:02: Start monitoring 192.168.31.1 2024/11/21 11:18:05: 192.168.31.1 is reachable 2024/11/21 11:18:20: 192.168.31.1 is reachable 2024/11/21 11:18:35: 192.168.31.1 is reachable 2024/11/21 11:18:50: 192.168.31.1 is reachable 2024/11/21 11:19:05: 192.168.31.1 is reachable Given that the syslog didn’t capture anything significant, I suspect this might be related to a kernel crash or perhaps a complete failure of network-related modules. Does anyone have advice on how I can further diagnose this issue? Are there specific kernel logs or tools that might help me narrow down the root cause? Thank you in advance for your insights! aio-diagnostics-20241121-1325.zip syslog-127.0.0.1.log

thanks reply, i will update os in a while

I've made some progress since my last post and wanted to share what I found, but I'm still facing some challenges and could really use some help. What I've Discovered After investigating the issue further, I realized that the "Host Access to Custom Networks" feature essentially creates a separate macvlan interface to facilitate communication between the host and Docker's macvlan. To work around my original issue, I manually created a vlan_bridge0 interface, and this allowed my Unraid host to communicate with the Docker macvlan network. As a result, I can now see the container-assigned IP addresses on my router, and they are accessible as expected. New Problem with WireGuard However, I'm encountering a new issue related to WireGuard. Here’s what I’ve done: Disabled NAT in WireGuard as per the guide. Added a static route on my router for the WireGuard subnet to route through the Unraid server. I can successfully ping devices through WireGuard, including those on the macvlan network. The problem: When I try to access web pages (HTTP) on the macvlan network through WireGuard, the connection is extremely slow—almost unusable. In contrast: Accessing other LAN IPs through WireGuard works perfectly and at normal speeds. Accessing the macvlan network from other LAN devices (not using WireGuard) is also fast and responsive. I'm unsure what could be causing this bottleneck when accessing the macvlan network through WireGuard, especially since ping works fine and other traffic is unaffected. Has anyone else experienced something similar or can offer advice on how to troubleshoot this further? Thanks again for your help! ip link add vlan_bridge0 link br0 type macvlan mode bridge ip addr add 192.168.31.2 dev vlan_bridge0 ip link set vlan_bridge0 up ip route add 192.168.31.4 dev vlan_bridge0

I'm encountering an issue while trying to enable the "Host access to custom networks" feature in Docker on my Unraid system. Despite configuring it according to the documentation, the setting fails to work as expected. I've captured some key logs that might shed light on the problem and I'll also include the relevant network configuration. System Information OS: Unraid 6.12.9 Key Logs Nov 14 10:37:07 AIO root: Error response from daemon: Pool overlaps with other one on this address space Nov 14 10:37:07 AIO root: RTNETLINK answers: Device or resource busy Nov 14 10:37:07 AIO kernel: br0: Device is already in use. Nov 14 10:37:07 AIO root: Device "shim-br0" does not exist. Nov 14 10:37:07 AIO root: Cannot find device "shim-br0" Nov 14 10:37:07 AIO root: /etc/rc.d/rc.docker: line 417: /proc/sys/net/ipv6/conf/shim-br0/disable_ipv6: No such file or directory Nov 14 10:37:07 AIO root: Cannot find device "shim-br0" Nov 14 10:37:07 AIO root: Cannot find device "shim-br0" Nov 14 10:37:07 AIO rc.docker: created network shim-br0 for host access Docker NetWorks NETWORK ID NAME DRIVER SCOPE ....... 49896d032498 docker_vlan macvlan local c4d14cdf4426 host host local 9b4eb889b406 none null local version: '3.3' services: ......... qbittorrent: image: 'linuxserver/qbittorrent:4.6.3' container_name: qbittorrent restart: always hostname: qbittorrent blkio_config: weight: 100 volumes: - '/mnt/user/appdata/qb/config:/config' - '/mnt/user/data/download:/download' tmpfs: - '/tmp' networks: docker_vlan: ipv4_address: 192.168.31.4 networks: docker_vlan: # 和宿主机同一个网络的情况下，只能创建这一个了 name: docker_vlan driver: macvlan driver_opts: parent: br0 # 使用的主机网络接口 ipam: config: - subnet: 192.168.31.0/24 gateway: 192.168.31.1 part of docker compose Host Network 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000 link/ipip 0.0.0.0 brd 0.0.0.0 6: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq master bond0 state UP group default qlen 1000 link/ether 84:47:09:00:06:b4 brd ff:ff:ff:ff:ff:ff 7: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq master bond0 state UP group default qlen 1000 link/ether 84:47:09:00:06:b4 brd ff:ff:ff:ff:ff:ff permaddr 84:47:09:00:06:b5 8: eth2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq master bond0 state UP group default qlen 1000 link/ether 84:47:09:00:06:b4 brd ff:ff:ff:ff:ff:ff permaddr 84:47:09:00:06:b6 9: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000 link/ether 84:47:09:00:06:b4 brd ff:ff:ff:ff:ff:ff 10: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 84:47:09:00:06:b4 brd ff:ff:ff:ff:ff:ff inet 192.168.31.170/24 brd 192.168.31.255 scope global dynamic noprefixroute br0 valid_lft 46690sec preferred_lft 35890sec ..........

Yes,and i submit as a issue

原贴已完结，是zfs设置的问题，具体请看原贴中的github链接。 简单来说就是得重新创建pool或者dataset 并且设置normalization=formC

It's work，thank you！ I checked the github of zfs and found an issue with a similar problem.This problem has not been solved yet.The temporary solution is to set normalization to formC. zfs issue 9965 I created a new dataset on unraid and tested successfully. root@AIO:~# zfs create -o mountpoint=/mnt/disk1/test -o normalization=formC disk1/test root@AIO:~# zfs list NAME USED AVAIL REFER MOUNTPOINT disk1 570M 53.2G 543M /mnt/disk1 disk1/test 96K 53.2G 96K /mnt/disk1/test ....... root@AIO:~# cd /mnt/disk1/test root@AIO:/mnt/disk1/test# ls root@AIO:/mnt/disk1/test# touch '[コテ絵] プリヤ達が催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちん おじさんに 認知不要ラブラブ種付け孕ませレイプさせて受精する本 (Fate kaleid liner プリズマイ.zip' root@AIO:/mnt/disk1/test# ls [コテ絵]\ プリヤ達が催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちん\ おじさんに\ 認知不要ラブラブ種付け孕ませレイプさせて受精する本\ (Fate\ kaleid\ liner\ プリズマイ.zip Next, I will recommend to unraid developers to use this setting when creating a zfs shared directory.

感觉是不是unraid的zfs问题很大啊。。。unraid的zfs应该也都是openzfs移植过来的吧

我发了英文版原贴。 Unraid版本6.12.9 zfs下复现，xfs下可以成功touch。之前truenas的zfs也是ok的。 心路历程： 使用docker的qbittorrent下载torrent时，一直报错，然后查看日志，发现可能是文件无法创建。然后使用touch手动创建文件的时候也就失败了，具体例子请看原贴。

If anybody who are using zfs, can you use the example I provided to execute touch to see if you have the same problem?

unraid version 6.12.9 disk3:->zfs When using docker's qbittorrent to download torrents, an error keeps reporting. Then I check the log and find that the file may not be created. log: (W) 2024-04-08T15:08:45 - File error alert. Torrent: "9月". File: "/download/manga/9月/2023-09-04/[コテ絵] プリヤ達が催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちん おじさんに 認知不要ラブラブ種付け孕ませレイプさせて受精する本 (Fate kaleid liner プリズマ☆イ.zip". Reason: "9月 file_open (/download/manga/9月/2023-09-04/[コテ絵] プリヤ達が 催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちんおじさんに 認知不要ラブラブ種付け孕ませレイプさせて受精する本 (Fate kaleid liner プリズマ☆イ.zip) error: Not supported" So I tried to create the file directly in the directory, and found that the creation failed when the file system was zfs, but it could be created normally when the file system was xfs: root@AIO:/mnt/disk3/data/download/manga/9月/2023-09-04# touch '[コテ絵] プリヤ達が催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちん おじさんに 認知不要ラブラブ種付け孕ませレイプさせて受精する本 (Fate kaleid liner プリズマイ.zip' touch: cannot touch '[コテ絵] プリヤ達が催眠術にかかったフリをしてロリコンキモデブ弱者男性粗ちん おじさんに 認知不要ラブラブ種付け孕ませレイプさせて受精する本 (Fate kaleid liner プリズマイ.zip': Operation not supported I have absolutely no idea why these files cannot be created on zfs, I have some examples as follows: