Date: Wed, 06 Mar 2019 23:07:50 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 236340] [FUSE] fuse(4) should pass through O_APPEND to the filesystem daemon Message-ID: <bug-236340-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236340 Bug ID: 236340 Summary: [FUSE] fuse(4) should pass through O_APPEND to the filesystem daemon Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org Currently when you open a fuse-backed file with O_APPEND, the kernel hides = the O_APPEND flag from the fuse filesystem and computes write offsets in fuse_write_directbackend. However, that behavior doesn't work for networked fuse filesystems. The problem is that two clients both writing to the same file with O_APPEND wouldn't cooperate to update the file size. Or to put it another way, implementing O_APPEND in-kernel requires cacheing the file size attribute, and cacheing attributes is not generally allowed for networked f= ile systems. The libfuse documentation makes it explicit that filesystems must handle the O_APPEND flag as of protocol 7.23. Implicitly, filesystems should handle i= t on older protocols as well. There are two possible approaches we could take: 1) Pass O_APPEND to FUSE_OPEN and set the offset of all FUSE_WRITE operatio= ns to 0 2) Pass O_APPEND to FUSE_OPEN but still compute the offset of all FUSE_WRITE operations as we do currently, expecting that compliant fuse filesystems wi= ll ignore it. I don't know how many fuse filesystems correctly handle O_APPEND, but I bet it's less than all of them. --=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-236340-227>