hoff

after reading the link above again, this is a workaround to fix a problem that is now occurring that didn't before. It was more than possible (I was running it) to operate IPLAN + Host Access with docker containers having IP's on br0 as the same subnet as my host and primary network. adding another docker network/vlan and reconfiguring everything is really not an option at this time. whats broken from previous versions?

I will read it again but that resolution includes moving all my containers that are not on the host network to another subnet and not my primary which is how ive operated for a long time, so changing the networking config of all my containers is going to be challenging with all my cross container application level integrations. As this worked pre 6.10.* there has to be a way? bug?

why do i have host access? I run a couple of mysql and other databases on lan_ip's on bridge and a number of services on host ports which need to talk to those other lan_ip's. A number of the out of the box apps in the repo dont like the br ip configuration which I would prefer for everything and ive been too lazy to fix all the apps that have issues not being on 'host' It might actually be time for unraid not to be my containers node at this point

Hi All. Looking at below, I am no expert in the shim-br0 but that seems to be the issue. I am thinking its might be a stale arp/mac issue as it takes a while to time out and then dies... If you are running a ping when the IPLAN + host access stops, there is no longer any transmit or recieve for anything offnet with a "tcpdump -nn -vv host 1.1.1.1" you cant see the tx or an rx on that packet, the box basically forgets how to get off its local subnet. Docker + IPLAN with Host Access ----------------------------------------------------------- root@Tower:~# arp -an | grep "80.1)" ? (10.80.80.1) at 7c:5a:1c:a2:7a:03 [ether] on shim-br0 ? (10.80.80.1) at <incomplete> on br0 16: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 14:18:77:4e:bf:d3 brd ff:ff:ff:ff:ff:ff inet 10.80.80.100/24 scope global br0 59: shim-br0@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 14:18:77:4e:bf:d3 brd ff:ff:ff:ff:ff:ff inet 10.80.80.100/32 scope global shim-br0 root@Tower:~# ip route default via 10.80.80.1 dev br0 10.80.80.0/25 dev shim-br0 scope link 10.80.80.0/24 dev br0 proto kernel scope link src 10.80.80.100 10.80.80.128/25 dev shim-br0 scope link 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 Docker on without Host Access ----------------------------------------------------- root@Tower:~# ip route default via 10.80.80.1 dev br0 10.80.80.0/24 dev br0 proto kernel scope link src 10.80.80.100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 Docker Off ------------------- root@Tower:~# arp -an | grep "80.1)" ? (10.80.80.1) at 7c:5a:1c:a2:7a:03 [ether] on br0 No shim-br0

@ljm42diag - IPLAN on. No Network traffic after a few mins. stop docker and external network access recovers. tower-diagnostics-20220618-1816.zip

confirmed also. MACLAN will cause a nf_nat fault and a kernel panic IPLAN will cause loss of connectivity and I will test the host access on as @aarontrycommented on at this point my unraid server is useless. I will upload a diagnostics with IPLAN and Host access on shortly.

Apologies. it failed back on IPVLAN. So it appears to be an issue with IPVLAN+Docker in 6.10.1/2

upload the diags here? So on 6.10.2 (VT-D Off in the Bios) the same thing happens but if I disable Docker(iplan) the system will behave correctly. Once Docker(iplan) is running and containers are booted, 1-2mins I loose all traffic external to my L2 domain/subnet. if I stop all containers remains "offline" outside my local layer2 network until I turn off Docker and then services return. I just tested the same with Docker(macvlan) and I am online and services appear to be working no issues. Switched back to Docker(ipvlan) and the problem has no not re-occured. *puzzled looks*

yeah, happens on 6.10.1 and 2. ill upgrade again now and retest.

Hi All. The problem is I lose connectivity to anything of my immediate L2 domain. I can ping the default gateway and manage the device, all is fine. Docker on/off causes loss of external network traffic. Dell R430 UNRAID server which has a tg3 NIC running Intel VT off/on no change. Docker only on IPVLAN to stop crashes from macvlan. Only Docker. The server boots and works as expected, can ping 1.1.1.1 as an example. Start RAID. still ok Start Docker. still ok. 1-5mins later, no external traffic. Stop Docker. Everything returns. MACvlan in the past has caused server locks IPvlan has resolved the lockups. Tested: VT on and off Test 6.10.1 and 6.10.2 no changes Any thoughts?

okay. This is all on my SAS connection I think in case someone else finds/reads this... [ 28.369041] mpt2sas_cm0: LSISAS2308: FWVersion(17.00.01.00), ChipRevision(0x05), BiosVersion(07.24.01.00) All my disks are desktop disks so sata so only single channel and I only have a single SAS cable connected Single Link on Dell H310 (1200MB/s*) <=- not my controller but close enough to be honest 8 x 137.5MB/s 12 x 92.5MB/s 16 x 70MB/s 20 x 55MB/s 24 x 47.5MB/s At the moment my array is made up of 8 disks in the tray and from a little more testing based on the data above, I seem to be able to have as many threads as I want as long as I dont go over ~70MB/s.... This puts me basically in the ballpark on the above... EDIT: after 15mins it died gain.... wonder how low I need to set it with threads to survive... So this is what the array can give me no more sooking about it.

To be clear guys. Appreciate getting 100MB is not happening due to limitations of unraid/etc. The bit that's driving me insane is the process hang/io timeouts causing the apps to fail and losing 8-10hours of copy time while asleep. I am going to leave RCLONE on single/20MB/s tonight and see what happens but that's 3days of copy time but better than nothing.... Tried all the RX/TX and flow control settings tonight too on both the source and destination. It seems to all be down to threads, the second I do more than 1 parallel copy it explodes and dies. 1 copy, 1 thread, with a BWlimit of 80MB/s and it seems stable... if ANYTHING happens on the box including my docker container backups, it basically explodes. Yes. Its a single SAS path as the disks are not DP/etc. I am going to investigate this part of it tomorrow.

Hi everyone. Just looking for a quick reality check on anything I have missed or if there is anything I can tune to make this rocket a bit more as I have spent close to 5 days just trying to copy data in without hangs/timeouts. Some of my source shares have large files which are okay on single thread, as they spool up and max the link for 10-120seconds. Extremely large files which take longer than 4-5mins seems to choke the box's writes and the whole platform dies. Small files such as my photo galleries on single thread are fine, but millions of small files I am looking at 2weeks to copy as if I go multiple threads on RCLONE they hang in the same way. Once the data is in there, its going to be consumed mainly via docker services and the off desktop mount point so I dont see long term read/writes having issues but this initial seed load is driving me insane Can I tweak any tunables somewhere I have not found around RAM/schedulers to help? Just finished building out a new Dell R430/Dell SC200 JBOD tray system. 2 x 6Core E5 CPU 96G RAM The system has 4 x SSD Cache Pool in the R430. 2 x 12TB Parity Drives (disabled at this time) 5 x 4TB 7200rpm 2 x 8TB 7200rpm Details of workload I am working to copy data from my old synology units which I have mounted at /tmp/source using NFS. I am copying data into /mnt/user/destination The share is setup with the maximum distribution which I can see if I browse the share in the UI. Cache Tier is disabled on this share due to data sizes Settings Docker - Disabled VM Managed - Disabled Turbo Write - Enabled Parity Drives - Removed Version: 6.9.0-rc2 Looking at above I should have the most efficient method available to me for copying data in. RSYNC will basically slow down from 100MB/s to 0.0001MB/s after about 30mins of work, basically dead. (Single Thread, No Compression, Local to Local copy) RCLONE seems to work better provided I limit it to 1 transfer and BW Limit it to about 70MB/s. If I use multiple threads on RCLONE it will basically melt and hang after about 20-25mins. Restarting any of the copies above resolves the issues. IOwait remains in single digits with a single copy thread and a BW limit of 80MB/s. 2 transfers and I see 3-10 iowait numbers on half the CPUs (rclone, shfs and unraidd* top threads) 4 transfers and I see 5-30 iowait on half the CPUs (rclone, shfs and unraidd* top threads) Initial Thoughts were: Parity Calc so removed the drives from the array Network speeds. Completed an iperf and sat at 900/900 on a 1Gps port for almost 8 hours last night. Turbo write mode which is mentioned a lot, enabled this. Disk issues. I have checked the smart on everything. the 12TB and 1 of the 8TB are brand new. The 8TBs are 6 months old, the 4TB are 16 months old and will be replaced with 8TB's that are 6 months old as soon as the synology sources are empty.

Version: 6.9.0-rc2 Same Issues. Array crash overnight 1 x Windows VM on br0 (only VM) 4 x Dockers on br0 Just moved the VM to br1 on another physical NIC and monitoring. So far no issues.

i had this issue too... any idea if there is a fix, my array shutdown is always dirty when power goes because of this.