From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-db5eur01on0119.outbound.protection.outlook.com ([104.47.2.119]:26752 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751216AbdHDTET (ORCPT ); Fri, 4 Aug 2017 15:04:19 -0400 Subject: Re: [fuse] writeback cache triggers read() for O_WRONLY files - bug? To: fuse-devel@lists.sourceforge.net References: <87tw1nuq49.fsf@vostro.rath.org> <87pocbupi1.fsf@vostro.rath.org> Cc: Miklos Szeredi , linux-fsdevel From: Maxim Patlasov Message-ID: Date: Fri, 4 Aug 2017 12:04:09 -0700 MIME-Version: 1.0 In-Reply-To: <87pocbupi1.fsf@vostro.rath.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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/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 >> >> -- >> GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F >> >> »Time flies like an arrow, fruit flies like a Banana.« >