Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp391862yba; Sun, 31 Mar 2019 02:06:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqyOGKQCz2TcQXoljSTV/+BYVJWCvM0RiB1426Rfw6PsdzNXEzjA0qNdKgiRmNmFRcpGx29L X-Received: by 2002:a17:902:7e49:: with SMTP id a9mr54836405pln.303.1554023187074; Sun, 31 Mar 2019 02:06:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554023187; cv=none; d=google.com; s=arc-20160816; b=tT9QNOH1KHYxPx8XNxhIb6EtEtfpAC1CuGp1c7/0oFlmfMwYqLtuB3nQhPUEWVAntc e3CaF0z0q9VodXDXVqcnYzIlxV4etocY4IUNZ/RTyC1Qx3Rjkc6LxG7eKVYbmSSZATu+ mywj4LeLqe+Jqri/FW+KMdXOkFQSqSTMWu6gej6euiMvv1TjZDOk9wP0u6+HQo2Vzou6 NN0zHc5cbU5Y5dJRLlee7jlTsYq2kunwnaIQa/KQ9MGSe/Pdn17b/O5k7/opLDaMvWeT 60fvldSfUv7g8homgtltXrR9YB2PZXOD96fOao+OzQ3w4i4Smtpnm94YkFoIcxWreAeB TW+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=CDSvKla9QFHpjjL1ySLqRwB0XQbUNLKE4UxyFBy4w1U=; b=xOkndgmxdge9upkt9GRCpr9/kNgVCd2CTw5AY+xPKNZmEouXg/5QGySqeYt9q/nG5R J153GCpCkSnuAxeZJ5bm4ypECpLdf8DgbbU6x/sq/u7o5YjSpaE0G/Xle8XEtpuPXk/L ReJMB88hbnLCYRlvkBfCR6sy7pahbmATyfLd3ki+MzN5RIlL2S7hVUKDkyJDwzidQw+B 4YIRgzGoXS5wQWHFg7lBNIfiVJP4ctXN9kPmYDMF9a2ZAqHRoY1xLxSF4SZDFKOAps/O wW021vigVIaPDI5vAedfmWtQw+s92AMBVLt5r/Haeu1Vi+iudoJjeswA/uJyWha1IpPS eajw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si6231181pfc.96.2019.03.31.02.06.12; Sun, 31 Mar 2019 02:06:27 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726950AbfCaJFe (ORCPT + 99 others); Sun, 31 Mar 2019 05:05:34 -0400 Received: from trent.utfs.org ([94.185.90.103]:50074 "EHLO trent.utfs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726710AbfCaJFc (ORCPT ); Sun, 31 Mar 2019 05:05:32 -0400 Received: from localhost (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 5531D5FB40; Sun, 31 Mar 2019 11:05:28 +0200 (CEST) Date: Sun, 31 Mar 2019 02:05:28 -0700 (PDT) From: Christian Kujau To: David Howells cc: linux-kernel@vger.kernel.org, Anna Schumaker , Steve Dickson Subject: Re: FS-Cache: Duplicate cookie detected In-Reply-To: <8939.1552374108@warthog.procyon.org.uk> Message-ID: References: <22096.1551878195@warthog.procyon.org.uk> <10106.1551892803@warthog.procyon.org.uk> <17155.1552056554@warthog.procyon.org.uk> <2827.1552315718@warthog.procyon.org.uk> <8939.1552374108@warthog.procyon.org.uk> User-Agent: Alpine 2.21.999 (DEB 277 2018-05-20) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David, On Tue, 12 Mar 2019, David Howells wrote: > > My /usr/local/src mount was mounted with vers=4.2 (default), while > > nfstest_cache was mounting its test-mount with vers=4.1! Apart from the > > different rsize/wsize values, the version number stood out. And indeed, > > when I mount my regular NFS mount /usr/local/src with vers=4.1, the > > "duplicate cookie" is no longer printed. > > Yeah - NFS superblocks are differentiated by a whole host of parameters, > including protocol version number, and caches aren't shared between > superblocks because this introduces a tricky coherency problem. > > The issue is that NFS superblocks to the same place do not currently manage > coherency (inode attributes, data) between themselves, except via the server. > > However, if "fsc" isn't given on the mount commandline, the superblock > probably shouldn't get a server-level cookie if we can avoid it. Just checking - are you waiting for new results from me, should I test something that I missed? Or are new patches in the works? :-D Thanks, Christian. -- BOFH excuse #139: UBNC (user brain not connected)