Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2180501ybg; Thu, 30 Jul 2020 12:25:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxEZmi4bexNvB2y5lWPXm5F7dtuCTxMKAWIeopkh9fbVYyJ6cR8/Wsycuy8t4iXpEEi7OCZ X-Received: by 2002:a05:6402:1841:: with SMTP id v1mr548992edy.198.1596137137501; Thu, 30 Jul 2020 12:25:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596137137; cv=none; d=google.com; s=arc-20160816; b=NfpKCZ2x0o6Tzz/nlwnipdjvLNJX8bm8sy7JPXwTNaUKOq1UP91SNnboN6vmmJOURW ++eQk+JRr5aF20+zIKfKlWYIuFtTO69Mq7DJzaPS4kLxbe2eQCACw9Bn2CWJx8Mgzwhg Z7d0c2bvdCxFaCl6YSKadJbE/TTkQvqpFl3htYNjbRBBowjYlLDfoKw2ZcC6bFvagY4y grk8QGb64109rFQaPBQtHxG+EQ66fsZXvdabdhT3bXQ1aNN3IGZdWBPquEayu9boEMgZ Z6lyuXub5G7XrZoXZpCGB8r1wB/W7wAoTxAf9oBb+JyxPTKbfpft+tpia847uZNeNMw6 1qKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+aT95YXKHydqNbmosDDInfhjNMhb1Txx1Ai8NlXUGyE=; b=uEHhBHNnUQtuakkT4cPTpqnB54FFYUIvDXz1qtseeHpZHSwMpkVnlpQP1yxisdBLbV D9lZdnutksgpQqK1FI103VITyqKL3rQH3WNPLrzLncPzmx8SouTNDZKRxJQlKjoWtJ1e WOJtZbfhUdVW6rS3OVm5k35bGmesFcum5Ef5RA18yvWx8CM8fL0/Kf2nOK9c7UhYdmgX ciB6eOpXPdZ3y+oDHAC4+U4vznRq9iXQxD06R3eQUM4w+ksjwj5kZlDUxzwMflJPhxkS MSCdDpZVXKAdKymVzKwX93jyHNzRi6aIleyfuFQt/CUxEdJ4mFe8x2UOyi509skmdOiy +4jA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Nt98Cg9X; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l7si3529735eja.172.2020.07.30.12.25.09; Thu, 30 Jul 2020 12:25:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Nt98Cg9X; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728616AbgG3TXy (ORCPT + 99 others); Thu, 30 Jul 2020 15:23:54 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:45728 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726581AbgG3TXx (ORCPT ); Thu, 30 Jul 2020 15:23:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1596137032; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+aT95YXKHydqNbmosDDInfhjNMhb1Txx1Ai8NlXUGyE=; b=Nt98Cg9XGC4bbcx0K/rvaJem26Ybjwc0jux/2Era4gHhJthoBDD+tukUiPHgOpon80pKGg oMf2/QQlfXoGOS4LJOw5ta3rL9UlemOAGp7R+weiTSkSLdtc+ZWxeNhNuycBPQzI90UDDR 62DvtXf9hRqhJL7K+6abpoNU5JAGM/4= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-497-ZYVn8Z8IM56mjJVVjr9-Ag-1; Thu, 30 Jul 2020 15:23:50 -0400 X-MC-Unique: ZYVn8Z8IM56mjJVVjr9-Ag-1 Received: by mail-ej1-f69.google.com with SMTP id d16so10224509eje.20 for ; Thu, 30 Jul 2020 12:23:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+aT95YXKHydqNbmosDDInfhjNMhb1Txx1Ai8NlXUGyE=; b=T2ngc9wvrapj743dEbkab6kmYcMrNUWNtDRbmfqiJO46lBW8vPk7vBUhhLpw3UhXhA 75+2M1FpUuj6qHtbt5x0lfX3llTvJpCZPdgKND7ggIx+6xvogoP9kq1vHjZ2FqGIAMdQ UKdRj3BVJYaUkPFKuG9igaXDsik6xY/JgdRuuaPOetfkjjCRCz37q0PhcvfgaEm+ErXp 7GMZq6CVVea6YmigXcrxYhN3X0u6/3ihGiFewU6aH+Wk42MeQEL+05WFGaVjg/pkOIC7 Nt/pKAohw1QtyyJnziV3+DKpFdqTe1L0m7oBderiC5CJvjsrqv9voN4TMDIbnrUdHslF V+fQ== X-Gm-Message-State: AOAM530aQA3R9wYG0Yn4IsBSTnb7eheUi/PhgGb/XWQKGuYurYrvKEOT ert7kdL6rqlnqzkmcBO/22iQjMlesIb6bQ8ihYNG9NSpX2zlueddrxQE9vwmdmNSyMSmZgFXsm6 dvz7fOuW/YoDAKfrjNgt0ZjLkF/l7Bcyw4Y86 X-Received: by 2002:a17:906:80d3:: with SMTP id a19mr603279ejx.217.1596137028989; Thu, 30 Jul 2020 12:23:48 -0700 (PDT) X-Received: by 2002:a17:906:80d3:: with SMTP id a19mr603265ejx.217.1596137028761; Thu, 30 Jul 2020 12:23:48 -0700 (PDT) MIME-Version: 1.0 References: <1596031949-26793-1-git-send-email-dwysocha@redhat.com> <1596031949-26793-14-git-send-email-dwysocha@redhat.com> <43e8a8ff1ea015bb7bd335d5616268d36155327a.camel@redhat.com> In-Reply-To: <43e8a8ff1ea015bb7bd335d5616268d36155327a.camel@redhat.com> From: David Wysochanski Date: Thu, 30 Jul 2020 15:23:12 -0400 Message-ID: Subject: Re: [Linux-cachefs] [RFC PATCH v2 13/14] NFS: Call fscache_resize_cookie() when inode size changes due to setattr To: Jeff Layton Cc: Trond Myklebust , Anna Schumaker , linux-nfs , linux-cachefs@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Jul 30, 2020 at 2:39 PM Jeff Layton wrote: > > On Wed, 2020-07-29 at 10:12 -0400, Dave Wysochanski wrote: > > Handle truncate / setattr when fscache is enabled by calling > > fscache_resize_cookie(). > > > > Signed-off-by: Dave Wysochanski > > --- > > fs/nfs/inode.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c > > index 45067303348c..6b814246d07d 100644 > > --- a/fs/nfs/inode.c > > +++ b/fs/nfs/inode.c > > @@ -667,6 +667,7 @@ static int nfs_vmtruncate(struct inode * inode, loff_t offset) > > spin_unlock(&inode->i_lock); > > truncate_pagecache(inode, offset); > > spin_lock(&inode->i_lock); > > + fscache_resize_cookie(nfs_i_fscache(inode), i_size_read(inode)); > > out: > > return err; > > } > > truncate can happen even when you have no open file descriptors on the > file and therefore w/o the cookie being "used". In the ceph vmtruncate > handling code, I do an explicit use/unuse around this call. Do you need > to do the same here? > -- > Jeff Layton > Actually I think the case you mention is covered by a patch that I've just added today on top of my v2 posting. This was the result of looking deeper into a few xfstest failures with NFSv4.2. I think this covers the truncate without a file open: commit 91d6922df9390ca1c090911be6e5c5ab1a79ea83 Author: Dave Wysochanski Date: Thu Jul 30 12:33:40 2020 -0400 NFS: Call fscache_invalidate() from nfs_invalidate_mapping() Be sure to invalidate fscache cookie for any call to nfs_invalidate_mapping(). This patch fixes the following xfstests on NFS4.x: generic/240 as well as fixes the following xfstests on NFSv4.2: generic/029 generic/030 Signed-off-by: Dave Wysochanski diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c index 6b814246d07d..62243ec05917 100644 --- a/fs/nfs/inode.c +++ b/fs/nfs/inode.c @@ -1233,6 +1233,7 @@ static int nfs_invalidate_mapping(struct inode *inode, struct address_space *map struct nfs_inode *nfsi = NFS_I(inode); int ret; + nfs_fscache_invalidate(inode, 0); if (mapping->nrpages != 0) { if (S_ISREG(inode->i_mode)) { ret = nfs_sync_mapping(mapping);