I added a 10GbE path to my NAS and throughput didn't move a single MB/s. NFSv4 was silently reusing the 1GbE link.

Spent an afternoon on this and every obvious check passed while it was happening,

so posting it in case it saves someone else the time.

**Setup:** Proxmox VE guest, Synology NAS, existing 1GbE path. Added a second,

faster 10GbE path and pointed the NFS mount at the new address.

Throughput: unchanged. 105 MB/s. Which, in hindsight, is suspiciously exactly

what a saturated 1GbE link gives you — that was the only clue anything was wrong.

**Everything you'd normally check says it's fine:**

$ mount | grep movies

10.0.1.31:/volume1/movies on /mnt/movies type nfs4 (rw,...) # new address ✓

$ ip route get 10.0.1.31

10.0.1.31 dev ens20 src 10.0.1.44 # new interface ✓

$ ping -c3 10.0.1.31

3 packets transmitted, 3 received # reachable ✓

**The cause is a real NFSv4 feature.** NFSv4.1+ can use multiple network paths to

one server. To do that the client has to decide whether two addresses are actually

the same server, which it works out with an `EXCHANGE_ID` call. If the server

answers with an identity the client already has a session with, the client treats

the new address as just another path to a server it's already connected to — and

reuses the existing transport rather than opening a new one.

So: you mount a different IP, the client asks who lives there, the answer is "the

server you're already talking to", and it keeps using the connection it had. Over

the old, slow link.

**The check that actually answers it** is interface counters. They can't be

talked into a wrong answer:

# before

$ cat /sys/class/net/ens20/statistics/rx_bytes

0

# read ~4 GB off the mount

$ dd if=/mnt/movies/some.large.file of=/dev/null bs=1M count=4000

# after

$ cat /sys/class/net/ens20/statistics/rx_bytes

0

Zero. All of it went out the old interface. After the fix the same test showed

~4,028 MB across that interface for a 4 GB read.

The general lesson I took from it: **throughput numbers and `mount` output are not

evidence about which link is carrying your traffic. Counters are.** I'd been

reading the mount options as proof of the data path, and they simply aren't.

**Fixes**, depending on what you want:

- `vers=3` on the mount — NFSv3 has no trunking detection, so it uses the path you

gave it. Bluntest and most reliable if you just want the fast link used.

- Keep v4 and give the two paths genuinely distinct server identities.

- Separately: `nconnect=8` took a VM from 299 → 553 MB/s on the same link. Single

virtio queue was the ceiling, not the network.

Full write-up with the `nfsstat -m` / `ss -tnp` output and the nconnect testing:

https://sonofatech.com/wiki/nfs-server-trunking-10g-mount.html

---