Date: Fri, 02 Jul 2021 20:45:40 +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-HHCrQ7O4yF@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 #6 from Alan Somers <asomers@FreeBSD.org> --- Ahh, well if moosefs is indeed using fusefs-libs3, then vfs.fusefs.data_cache_mode is completely ignored. Instead, the cache behav= ior is controlled by moosefs itself. You can tell what it's requesting by look= ing at the FUSE_INIT response, either by dialing up the log verbosity (maybe, depending on if moosefs displays it), or by running this (untested) dtrace script at mount time fusefs:fusefs:internal:init_done { printf("flags=3D%s", args[1]->flags); } Another important thing that the server tells the kernel is the entry and a= ttr valid timeouts, which are returned by FUSE_LOOKUP. Finally, there is the AUTO_INVAL_DATA feature (known as FUSE_CAP_AUTO_INVAL_DATA in libfuse). This would probably be very useful f= or MooseFS. In fact, MooseFS may well be written assuming that the feature is available and working. However, it is not currently implemented in FreeBSD. --=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-HHCrQ7O4yF>