From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:48751 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751216AbdHDTA5 (ORCPT ); Fri, 4 Aug 2017 15:00:57 -0400 From: Nikolaus Rath To: fuse-devel@lists.sourceforge.net, Maxim Patlasov , Miklos Szeredi , linux-fsdevel Subject: Re: [fuse] writeback cache triggers read() for O_WRONLY files - bug? References: <87tw1nuq49.fsf@vostro.rath.org> Date: Fri, 04 Aug 2017 21:00:54 +0200 In-Reply-To: <87tw1nuq49.fsf@vostro.rath.org> (Nikolaus Rath's message of "Fri, 04 Aug 2017 20:47:34 +0200") Message-ID: <87pocbupi1.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 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/issues= /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