Date: Tue, 22 Oct 2024 09:10:21 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 230259] [FUSEFS] [BUG]: File close (release) issue Message-ID: <bug-230259-3630-XWgKk2RbBs@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230259-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-230259-3630@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=3D230259 Agata <chogata@moosefs.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chogata@moosefs.com --- Comment #17 from Agata <chogata@moosefs.com> --- Hi, MooseFS Team here :) We tested newer FreeBSD behaviour and we can see that INTERRUPT is sent to the reading process. But both 13.2 and 14.1 versions s= till don't wait for confirmation (neither for the read to end or that INTERRUPT = was received), they just sent RELEASE. As was stated before, MooseFS has reference counters anyway, so it handles = the interrupts correctly anyway. Other filesystems using FUSE may not, and if t= hat is the case, their read operations, that get interrupted, may behave unexpectedly (and even end with a segfault). Since Linux kernel waits for t= he read to finish, those filesystems will behave differently there. Linux and FreeBSD are two main systems that implement FUSE, so we kind of feel oblige= d to point this out to you, that's why this thread was first created. But it's = not a direct issue for our filesystem, if that is what you are asking. --=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-230259-3630-XWgKk2RbBs>