Return-Path: Received: from mail-ob0-f178.google.com ([209.85.214.178]:32813 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752236AbcC3Sxh (ORCPT ); Wed, 30 Mar 2016 14:53:37 -0400 Received: by mail-ob0-f178.google.com with SMTP id x3so79017340obt.0 for ; Wed, 30 Mar 2016 11:53:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160330185026.GC12525@fieldses.org> References: <20160330174040.GA12525@fieldses.org> <20160330185026.GC12525@fieldses.org> Date: Wed, 30 Mar 2016 14:53:27 -0400 Message-ID: Subject: Re: out of order v3 write replies and cache invalidation From: Trond Myklebust To: "J. Bruce Fields" Cc: Olga Kornievskaia , linux-nfs Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Mar 30, 2016 at 2:50 PM, J. Bruce Fields wrote: > On Wed, Mar 30, 2016 at 02:43:38PM -0400, Trond Myklebust wrote: >> On Wed, Mar 30, 2016 at 2:39 PM, Olga Kornievskaia wrote: >> > On Wed, Mar 30, 2016 at 2:20 PM, Trond Myklebust >> > wrote: >> >> On Wed, Mar 30, 2016 at 1:40 PM, J. Bruce Fields wrote: >> >>> If we assume no other writers until we close, couldn't you on close wait >> >>> for all writes, send a final getattr for change attribute, and trust >> >>> that? If the extra getattr's too much, then you'd need some algorithm >> >>> like the above to determine which change attribute is the last. Or >> >>> implement >> >>> https://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-41#section-12.2.3 >> >>> on client and server and just track the maximum returned value when the >> >>> server returns something other than NFS4_CHANGE_TYPE_IS_UNDEFINED. >> >>> >> >> >> >> The correct tool to use for resolving these caching issues is >> >> ultimately a write delegation. >> >> >> >> You can also eliminate a lot of invalidations if you know that the >> >> server implements change_attr_type == >> >> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER or >> >> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER_NOPNFS, since that allows you to >> >> predict what the attribute should be after a change. >> > >> > Thanks for all the info. But let me highlight that I was asking about >> > v3. I don't see that the code has issues with cache invalidation for >> > nfsv4 when receiving out-of-order RPCs. >> > >> > I am not sure if it's worth implementing something that Bruce >> > suggests. I just wanted to make sure that what i'm seeing is >> > "expected" behavior (caz it's v3) and not a bug. >> >> Yes. The design does expect the occasional false positive cache >> invalidation due to RPC request reordering. > > In the v3 and close-to-open case, since the ctime's monotonically > increasing, why couldn't we just keep track of the maximum ctime seen > before close? We can do that, but in theory NFSv3 is supposed to observe weak cache consistency rather than strict close-to-open. In practice, we probably don't care.