Date: Sat, 11 Feb 2023 23:42:50 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 211674] sysutils/fusefs-ntfs: fuse_vnode leak/reclamation failure Message-ID: <bug-211674-7788-oICEymmOpL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211674-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-211674-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211674 --- Comment #11 from Alan Somers <asomers@FreeBSD.org> --- Ok, here are the results of my investigations: 1) It's not a problem that the vnode number keeps rising. The kernel doesn= 't reclaim vnodes as soon as all their file descriptors get closed. Rather, t= he vnodes remain allocated just in case the same file system decides it needs = to use some more. The kernel won't reclaim vnodes until unmount or until it starts to run low on vnodes, possibly due to activity on some other file system. 2) It's mostly not a problem that the fuse_msgbuf value keeps rising (but s= ee caveat below). Similarly to the vnode situation, uma does not free items as soon as they are no longer needed. But it will free them in response to me= mory pressure. See uma(9). 3) There are some actual resource leaks, which can be observed by the value= of "sysctl vfs.fusefs.stats.ticket_count". Those are probably responsible for some of the fuse_msgbuf memory consumption, but probably a minority. I'll = work on fixing these. The first one I found is in an error path, triggerable by= a malicious server. 4) You probably aren't the only person to notice slow unmounts. That's probably why the FUSE protocol describes a BATCH_FORGET operation. It isn't implemented in FreeBSD, but probably could be. I don't know if fuse-ntfs is able to take advantage. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211674-7788-oICEymmOpL>