NFS exporting mergerfs with a mix of RO and RW mounts and func.readdir=cor will randomly list the same file twice

[slqy123]

Describe the bug & To Reproduce
I have /mnt/disk-ro/p* mounted ro, and /mnt/disk/d* mounted rw

all the disks are mounted with:
UUID=xxx /mnt/disk/p1 btrfs <rw/ro>,users,autodefrag,noatime,compress=zstd 0 0

mergerfs mount:
/mnt/disk-ro/*=RO:/mnt/disk/d* /mnt/all mergerfs config=/etc/mergerfs/default.ini 0 0

/etc/mergerfs/default.ini:
cache.files=off
dropcacheonclose=false
func.readdir=cor:4
func.getattr=newest
category.create=mspmfs
minfreespace=16G
never-forget-nodes=true
inodecalc=path-hash
lazy-umount-mountpoint=false

nfs exports:
/mnt/all *(rw,sync,fsid=691a181c-a718-44a7-a0fd-50e5a9c08bae,insecure,nohide,no_root_squash)

1. create example files in every disk
2. export with NFS and keep trying ls on client side
3. Sometimes ls will show:

# d1-1 ~ d1-7 are missing
12063579590297766028 .rw-r--r--@ 0 quy 23 Nov 17:30 d1-8
 1009218104580372872 .rw-r--r--@ 0 quy 23 Nov 17:30 d1-9
10226916096750517555 .rw-r--r--@ 0 quy 23 Nov 17:30 d2-0
 9148699206468856763 .rw-r--r--@ 0 quy 23 Nov 17:30 d2-1
...
 3995154008875108500 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-6    <--
 3995154008875108500 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-6    <-- p2-6 show twice
 4991125370245759905 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-7
 4991125370245759905 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-7
 4736725953109485646 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-8
 7456473207889864599 .rw-r--r--@ 0 quy 23 Nov 17:30 p2-9
# the total amount of files is correct

but when I use func.readdir=cosr, everything is OK.

System information:

• OS, kernel version: ArchLinux, Linux PC 6.17.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 14 Nov 2025 06:54:20 +0000 x86_64 GNU/Linux
• mergerfs version: mergerfs v2.41.0
• mergerfs settings: see above
• A strace of the application having a problem: app.strace.txt
• strace of mergerfs while app tried to do it's thing: mergerfs.strace.txt

[trapexit]

The code to dedup names is the same between the two so off hand not seeing what the problem could be.

BTW those traces are not aligned. The ls was at 18:34:48.274624 but the mergerfs trace is from 18:39:29.992201.

[trapexit]

It's not clear from your post... is this only when doing ls from the NFS client side?

If "yes"... I wonder if it has to do with the ordering changing and maybe some caching on NFS's side causing it to act funny. The ls you show clearly shows duplicates but the code looks correct and locally (not using NFS) it looks fine.

[slqy123]

BTW those traces are not aligned. The ls was at 18:34:48.274624 but the mergerfs trace is from 18:39:29.992201.

app.strace.txt
mergerfs.strace.txt

It's not clear from your post... is this only when doing ls from the NFS client side?

Yes, only on the client side.

---

I can stably reproduce this bug with a simple setup:

mkdir ro rw mergerfs
touch ro/ro{0..9} rw/rw{0..9}
mergerfs -o cache.files=off,dropcacheonclose=false,func.readdir=cor,func.getattr=newest,category.create=mspmfs,never-forget-nodes=true,inodecalc=path-hash,lazy-umount-mountpoint=false $PWD/ro=RO:$PWD/rw $PWD/mergerfs/

NFS exports:

/mnt *(rw,sync,fsid=root,insecure,nohide,crossmnt,no_root_squash)
/mnt/a/mergerfs *(rw,sync,fsid=3c4b7103-bd04-4a2a-8092-f167e95e598a,insecure,nohide,no_root_squash)

client fstab:

<server>:/a/mergerfs /mnt/test nfs defaults,_netdev,nofail 0 0

/mnt/test
❯ ls
ro0  ro1  ro2  ro3  ro4  ro5  ro6  ro7  ro8  ro8  ro9  ro9  rw0  rw1  rw2  rw3  rw4  rw5  rw6  rw7

/mnt/test
❯ ls | uniq -d
ro8
ro9

[trapexit]

Your mergerfs strace doesn't contain directory listing requests (getdents64). My guess is you queried it prior to the trace and NFS had cached it.

I'll see if I can reproduce it but I am on holiday this week. I would suggest also trying to disable any relevant caching on NFS's side. Perhaps it just isn't a good idea to mix these and I'll have to mention it in the docs.