From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:35577 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbdHDTNV (ORCPT ); Fri, 4 Aug 2017 15:13:21 -0400 From: Nikolaus Rath To: Maxim Patlasov Cc: fuse-devel@lists.sourceforge.net, Miklos Szeredi , linux-fsdevel Subject: Re: [fuse] writeback cache triggers read() for O_WRONLY files - bug? References: <87tw1nuq49.fsf@vostro.rath.org> <87pocbupi1.fsf@vostro.rath.org> Date: Fri, 04 Aug 2017 21:13:12 +0200 In-Reply-To: (Maxim Patlasov's message of "Fri, 4 Aug 2017 12:04:09 -0700") Message-ID: <87ini3uoxj.fsf@vostro.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Maxim, Any reason the kernel doesn't fix up the flags before sending the open request? I assume the kernel will enforce that userspace can't read from a file opened with O_WRONLY if writeback cache is enabled? Is the same also true without writeback cache, i.e. can the filesystem safely ignore O_WRONLY/O_RDONLY at all times? Thanks! -Nikolaus On Aug 04 2017, Maxim Patlasov wrote: > Hi Nikolaus, > > > If writeback caching is enabled, libfuse must be prepared to get READ > requests from kernel. Hence, even if an user wants WRONLY, libfuse > should open RDWR. > > > Thanks, > > Maxim > > > On 08/04/2017 12:00 PM, Nikolaus Rath wrote: >> Hi again, >> >> Small clarification: the O_APPEND flag muddles the water a bit (I'll >> write a second mail about that). The behavior that I'm describing here >> also happens if userspace opens without O_APPEND but seeks to the end of >> the file before writing. >> >> Best, >> -Nikolaus >> >> On Aug 04 2017, Nikolaus Rath wrote: >>> Hello, >>> >>> When enabling writeback cache for SSHFS, appending to files overwrites >>> data at a different position (cf. https://github.com/libfuse/sshfs/issu= es/72). >>> >>> When trying to track this issue down, I noticed that the libfuse >>> passthrough_ll example also has problems with appending: calling >>> fuse_reply_data gives a "Bad File Descriptior" error. >>> >>> This in turn I traced this down to the fact that when writeback caching >>> is enabled, and userspace calls open(name, O_WRONLY|O_APPEND) the kernel >>> passes the O_WRONLY flag on to libfuse. But when userspace then writes >>> data, the kernel issues a read() request to libfuse (presumably to fill >>> the write cache) - for a file that has been opened write-only. >>> >>> In the passthrough_ll example, this then fails because the underlying >>> file has also been opened O_WRONLY and the strace read then fails. >>> >>> I am not sure what to make of this. Is this behavior of the kernel >>> correct? Should libfuse be prepared to accept READ requests for files >>> that have been opened write-only? Or should the kernel never open files >>> write-only when writeback caching is enabled? >>> >>> (I am not sure if something like this is also the cause of the >>> dataloss problem in SSHFS, but it seems worth addressing in any case) >>> >>> Thanks, >>> -Nikolaus >>> >>> --=20 >>> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F >>> >>> =C2=BBTime flies like an arrow, fruit flies like a Banana= .=C2=AB >> > > --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB