Date: Sun, 16 Feb 2020 22:17:40 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244178] [FUSEFS]: underlying file modified leads to corrupted fuse data Message-ID: <bug-244178-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244178 Bug ID: 244178 Summary: [FUSEFS]: underlying file modified leads to corrupted fuse data Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: ben.rubson@gmx.com Hi, I still face, with 12.1-RELEASE-p2, the issue discussed here : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230258#c35 Which continued there : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235774 The issue is the following. Let's assume raw file is the underlying file. And fuse file the corresponding fuse file. 1. create raw file with some data 2. open fuse file 3. verify fuse size : correct 4. verify fuse data : correct 5. add some data to raw file 6. verify fuse size : correct (*) 7. verify fuse data : garbage (*) as expected we have to use fuse options attr_timeout=3D0 entry_timeout= =3D0. So, if we keep the fuse file opened, while the underlying one is modified : - we read the fuse file up to the expected size, perfect ; - but we read garbage. If we close and re-open the fuse file, then we correctly read it. There are 2 possible workarounds : - use FUSE direct_io mount option ; - sysctl vfs.fusefs.data_cache_mode =3D 0. I don't know whether or not the default behavior is correct. But at least with Linux, we correctly read the data even keeping the fuse f= ile opened. There may then still be a cache issue. Many thanks for your feedback ! --=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-244178-227>