From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com ([66.111.4.25]:41863 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751791AbdIURxv (ORCPT ); Thu, 21 Sep 2017 13:53:51 -0400 From: Nikolaus Rath To: Maxim Patlasov Cc: mszeredi@redhat.com, "fuse-devel\@lists.sourceforge.net" , linux-fsdevel Subject: Re: [fuse-devel] [fuse] getattr() results ignored when writeback cache is active References: <87zi9pk2ra.fsf@vostro.rath.org> <87vakdjsjj.fsf@vostro.rath.org> <87y3p8uzpw.fsf@vostro.rath.org> <11acc9f1-12e5-9806-48ff-de261acae979@virtuozzo.com> Date: Thu, 21 Sep 2017 18:53:45 +0100 In-Reply-To: <11acc9f1-12e5-9806-48ff-de261acae979@virtuozzo.com> (Maxim Patlasov's message of "Thu, 21 Sep 2017 10:28:31 -0700") Message-ID: <87wp4s9bva.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 21 2017, Maxim Patlasov wrote: > On 09/21/2017 03:12 AM, Nikolaus Rath wrote: > >> On Sep 20 2017, Miklos Szeredi wrote: >>> In writeback-cache mode (enabled by the FUSE_WRITEBACK_CACHE flaga) wri= tes go to >>> the cache only, which means that the write(2) syscall can often complet= e very >>> fast. The dirty pages are later sent to userspace using write requests= . This >>> mode assumes that the file is never changed outside the mounted filesys= tem, so >>> it's not suitable for any network fs. >> .."this mode of operation is not suitable for any network filesystem >> even if no write operations are actually carried out". > > Not true. A network filesystem can guarantee that the file is never > changed outside by implementing exclusive write lease semantics: when > someone opens file for writing first time the metadata server grants > exclusive rights for that mount, then declines all subsequent open > requests from other mounts; and similarly while a file is being kept > opened for reading, the metadata server declines all open-for-writing > requests from other mounts. In practice that doesn't seem to work, see the example in my first message. The file is only ever accessed on one mount at a time, yet the changes do not propagate (and would result in data corruption if another mount would attempt to read or modify the file afterwards). 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