Date: Mon, 23 Mar 2026 14:00:16 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293957] Kernel Panic in fusefs: page fault (0x78) in fuse_vnop_write during vnode recycling (csync2 synchro) Message-ID: <bug-293957-227-ZMQI6GYpOm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-293957-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293957-227-ZMQI6GYpOm>