From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2E7B9C4338F for ; Mon, 9 Aug 2021 04:20:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0867D60F4B for ; Mon, 9 Aug 2021 04:20:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231157AbhHIEU4 (ORCPT ); Mon, 9 Aug 2021 00:20:56 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:57922 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230394AbhHIEUz (ORCPT ); Mon, 9 Aug 2021 00:20:55 -0400 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6AB3C21EF4; Mon, 9 Aug 2021 04:20:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1628482834; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tdKSDNL+pofpSnFf046QHB3TogSAInmiCBDTxi7b0R4=; b=WQKDVF22d58/+3BMKqmcrLG54rrXRkkAPNv4PpG3nZ1aSzSZUzgmgvuTRXQMb73ITNvbKy su3yPF/XMfPV6T4MaJ9wrg74/2uNHG7cACfQem1lJxbCdVmBIjryKLOTBV4wEIi/HGSx92 ADL7afVJGjRYzBzqhncI9c6p6b4TGqY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1628482834; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tdKSDNL+pofpSnFf046QHB3TogSAInmiCBDTxi7b0R4=; b=5jrpDZb4X1vR3tkpCnQ45dMCT7L6jcwbf3P3Oom/D/YWMc3pNogANsQK5CrQRXI2LhCHX4 yik4ZEb8e8fVuPAA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C1D0313398; Mon, 9 Aug 2021 04:20:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Dg1THxCtEGHmCgAAMHmgww (envelope-from ); Mon, 09 Aug 2021 04:20:32 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "NeilBrown" To: "Trond Myklebust" Cc: "bfields@fieldses.org" , "plambri@redhat.com" , "linux-nfs@vger.kernel.org" , "bcodding@redhat.com" Subject: Re: cto changes for v4 atomic open In-reply-to: References: , , <20210803203051.GA3043@fieldses.org>, <3feb71ab232b26df6d63111ee8226f6bb7e8dc36.camel@hammerspace.com>, <20210803213642.GA4042@fieldses.org>, , <162803443497.32159.4120609262211305187@noble.neil.brown.name>, <08db3d70a6a4799a7f3a6f5227335403f5a148dd.camel@hammerspace.com>, <162803867150.32159.9013174090922030713@noble.neil.brown.name>, , <162804062307.32159.5606967736886802956@noble.neil.brown.name>, Date: Mon, 09 Aug 2021 14:20:26 +1000 Message-id: <162848282650.22632.1924568027690604292@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, 04 Aug 2021, Trond Myklebust wrote: > On Wed, 2021-08-04 at 11:30 +1000, NeilBrown wrote: > > Caching not a "best effort" attempt. The client is expected to provide > a perfect reproduction of the data stored on the server in the case > where there is no close-to-open violation. > In the case where there are close-to-open violations then there are two > cases: > > 1. The user cares, and is using uncached I/O together with a > synchronisation protocol in order to mitigate any data+metadata > discrepancies between the client and server. > 2. The user doesn't care, and we're in the standard buffered I/O > case. > > > Why are you and Bruce insisting that case (2) needs to be treated as > special? I don't see these as the relevant cases. They seem to assume that "the user" is a single entity with a coherent opinion. I don't think that is necessarily the case. I think it best to focus on the behaviours, and intentions behind, individual applications. You said previously that NFS doesn't provide caches for applications, only for whole clients. This is obviously true but I think it misses an important point. While the cache belongs to the whole client, the "open" and "close" are performed by individual applications. close-to-open addresses what happens between a CLOSE and an OPEN. While it may be reasonable to accept that any application must depend on correctness of any other application with write access to the file, it doesn't necessary follow that any application can only be correct when all applications with read access are well behaved. If an application arranges, through some external means, to only open a file after all possible writing application have closed it, then the NFS caching should not get in the way for the application being able to read anything that the other application(s) wrote. This, it me, is the core of close-to-open consistency. Another application writing concurrently may, of course, affect the read results in an unpredictable way. However another application READING concurrently should not affect an application which is carefully serialised with any writers. Thanks, NeilBrown