[Bug 293957] Kernel Panic in fusefs: page fault (0x78) in fuse_vnop_write during vnode recycling (csync2 synchro)
Date: Mon, 23 Mar 2026 14:00:16 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293957
--- Comment #3 from zjk <zjk7@wp.pl> ---
Subject: Additional observations regarding vnode recycling and stability
I have more data points that might help pinpoint the problem in fusefs.
Observations:
The Panic Trigger: I've confirmed that the panic (page fault 0x78 in
fuse_vnop_write) consistently occurred exactly when vfs.numvnodes reached the
kern.maxvnodes limit (initially set to 500000, and then 2,000,000).
Workload Context: This happens on 2 out of 8 hosts in a cluster. These 2
hosts run heavy Apache/httpd traffic on MooseFS (FUSE) mounts. The other 6
hosts, which have lower file activity (around 500,000 vnodes), remained
perfectly stable even with the 500000 limit (in this hosts are 3 file servers
with moosefs source).
Current Stability: After increasing kern.maxvnodes to 3,000,000 for 2
apache servers and setting vfs.fusefs.data_cache_mode=0, the systems have
become stable. But today I dont make a sync (csync rsync).
Current Stats: On the problematic hosts, vfs.numvnodes has now stabilized
at approximately 2,050,000.
When the limit was 2,000,000, maybe the system was forced into
aggressive vnode reclamation/recycling, which triggered the crash.
Hypothesis:
The crash seems to be a race condition triggered by the vnode reclamation
process. When the kernel tries to retire an inactive FUSE vnode under memory
pressure, fuse_vnop_write is called (likely for a dirty page or metadata sync)
and encounters a NULL pointer (offset 0x78).
Current Workaround Settings:
vfs.fusefs.data_cache_mode=0
vfs.fusefs.iov_credit=4 (reduced from 128)
kern.maxvnodes=3000000
Mount options: noatime (to reduce metadata writes)
But - once more - I dont make today sync test with csync2/rsync (I need more
time and It must be time with "crash enable" for www-servers ;) ).
Best regards
zjk
--
You are receiving this mail because:
You are the assignee for the bug.