[Bug 293957] Kernel Panic in fusefs: page fault (0x78) in fuse_vnop_write during vnode recycling (csync2 synchro)

From: <bugzilla-noreply_at_freebsd.org>
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.