From owner-freebsd-bugs@freebsd.org Sun Feb 16 22:17:40 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E0AE6244B1D for ; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48LM1c5gbrz3MJD for ; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id C2737244B1C; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C23C9244B1B for ; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48LM1c4VM2z3MJ1 for ; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 957952CC61 for ; Sun, 16 Feb 2020 22:17:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 01GMHeB2092699 for ; Sun, 16 Feb 2020 22:17:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 01GMHeIA092698 for bugs@FreeBSD.org; Sun, 16 Feb 2020 22:17:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 244178] [FUSEFS]: underlying file modified leads to corrupted fuse data Date: Sun, 16 Feb 2020 22:17:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ben.rubson@gmx.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2020 22:17:40 -0000 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.=