Date: Fri, 02 Jul 2021 19:36:25 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 256936] Buggy filesystem detected - message wrongly triggered by FUSE filesystems Message-ID: <bug-256936-3630-3ZaY03HFkm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256936-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-256936-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=3D256936 --- Comment #2 from Alan Somers <asomers@FreeBSD.org> --- If the FUSE daemon tells the kernel that it may cache dirty data, but then = the daemon tells the kernel that the file has changed while it was dirty, then = data has been lost. Data corruption is a bug. MooseFS's hands are somewhat tied as it still uses fusefs-libs2. At that protocol level there really aren't sufficient operations for the server to manage the kernel's cache. But sshfs uses fusefs-libs3, so it ought to be = able to fix the problem. If it's possible to prove that no data corruption occurred and yet the kern= el still prints this error message, then that would constitute a bug in the kernel, and I would fix it. The most obvious way for that to happen is if = you set vfs.fusefs.data_cache_mode=3D0, completely disabling the cache. But ev= en if data_cache_mode=3D1, it wouldn't surprise me if there are cases where the w= arning is printed inappropriately; it's complicated. Especially because file attributes can be cached independently of their data. --=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-256936-3630-3ZaY03HFkm>