From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46193 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbdITPbP (ORCPT ); Wed, 20 Sep 2017 11:31:15 -0400 From: Nikolaus Rath To: Miklos Szeredi Cc: fuse-devel@lists.sourceforge.net, Maxim Patlasov , linux-fsdevel Subject: Re: [fuse-devel] [fuse] getattr() results ignored when writeback cache is active References: <87zi9pk2ra.fsf@vostro.rath.org> Date: Wed, 20 Sep 2017 16:31:12 +0100 In-Reply-To: (Miklos Szeredi's message of "Wed, 20 Sep 2017 17:23:16 +0200") Message-ID: <87vakdjsjj.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: On Sep 20 2017, Miklos Szeredi wrote: > On Wed, Sep 20, 2017 at 1:50 PM, Nikolaus Rath wrote: >> Hi, >> >> I'm having another problem with FUSE's writeback cache in SSHFS. >> >> As far as I can tell, the FUSE kernel module issues getattr() requests, >> but then silently discards the reported mtime and file size. >> >> For SSHFS, this means that if a file has been accessed, and is then >> changed on the server, the changed attributes don't make it to the >> client and the file appears truncated or \0-filled. >> >> To me this looks like a bug.. am I missing something? > > Writeback cache assumes that the file is never changed outside the > mounted filesystem, so it's not suitable for any network fs currently. > > Apparently the above is not documented anywhere :( Ouch. I will of course put this into the libfuse documentation, but it would be much nicer if things like that could be documented somewhere in the kernel. After all, these are not properties of libfuse but the kernel module - and some filesystems use the fuse interface without using libfuse. (This actually applies to large chunk of information that's currently only in the libfuse documentation). Any chance of that happening? I understand that bringing Documentation/filesystems/fuse.txt up to date would be a major endeavour, but maybe one could just start by putting at least this information into e.g. a new Documentation/filesystems/fuse/writeback.txt file? Together with the requirement that the filesystem has to support reading from files opened O_WRONLY? Best, -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