linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Wysochanski <dwysocha@redhat.com>
To: Jeff Layton <jlayton@redhat.com>, David Howells <dhowells@redhat.com>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	linux-nfs <linux-nfs@vger.kernel.org>,
	linux-cachefs@redhat.com
Subject: Re: [Linux-cachefs] [RFC PATCH v2 13/14] NFS: Call fscache_resize_cookie() when inode size changes due to setattr
Date: Thu, 30 Jul 2020 15:59:34 -0400	[thread overview]
Message-ID: <CALF+zOn9tSft_QkPaJ7w8v_OLTfon+acUB_W9MSb8EEMQGc94w@mail.gmail.com> (raw)
In-Reply-To: <CALF+zOnYLbibbYxvbyUJFJQ+NtcreuAvFkZYr9h3_qQswbMxRw@mail.gmail.com>

On Thu, Jul 30, 2020 at 3:23 PM David Wysochanski <dwysocha@redhat.com> wrote:
>
> On Thu, Jul 30, 2020 at 2:39 PM Jeff Layton <jlayton@redhat.com> 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 <dwysocha@redhat.com>
> > > ---
> > >  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 <jlayton@redhat.com>
> >
>
> 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 <dwysocha@redhat.com>
> 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 <dwysocha@redhat.com>
>
> 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);


Actually the above patch fixes truncates when a file is open, not the
case that Jeff mentions.

To be honest I'm not sure about needing a call to fscache_use/unuse_cookie()
around the call to fscache_resize_cookie().  If the cookie has a
refcount of 1 when it is created, and a file is never opened, so
we never call fscache_use_cookie(), what might happen inside
fscache_resize_cookie()?  The header on use_cookie() says
/*
 * Start using the cookie for I/O.  This prevents the backing object from being
 * reaped by VM pressure.
 */

But we're not using it for I/O in this case.
I will have to dig deeper to be sure, or maybe David H will elaborate further.


  reply	other threads:[~2020-07-30 20:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-29 14:12 [RFC PATCH v2 0/14] Convert NFS to new FS-Cache iter API Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 01/14] NFS: Clean up nfs_readpage() and nfs_readpages() Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 02/14] NFS: In nfs_readpage() only increment NFSIOS_READPAGES when read succeeds Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 03/14] NFS: Refactor nfs_readpage() and nfs_readpage_async() to use nfs_readdesc Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 04/14] NFS: Call readpage_async_filler() from nfs_readpage_async() Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 05/14] NFS: Add nfs_pageio_complete_read() and remove nfs_readpage_async() Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 06/14] NFS: Allow internal use of read structs and functions Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 07/14] NFS: Convert nfs_readpage() and readpages() to new fscache API Dave Wysochanski
2020-08-04 17:41   ` [Linux-cachefs] " David Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 08/14] NFS: Convert fscache_acquire_cookie and fscache_relinquish_cookie Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 09/14] NFS: Only use and unuse an fscache cookie a single time based on NFS_INO_FSCACHE Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 10/14] NFS: Convert fscache invalidation and update aux_data and i_size Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 11/14] NFS: Call nfs_fscache_invalidate() when write extends the size of the file Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 12/14] NFS: Invalidate fscache for direct writes Dave Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 13/14] NFS: Call fscache_resize_cookie() when inode size changes due to setattr Dave Wysochanski
2020-07-30 18:39   ` [Linux-cachefs] " Jeff Layton
2020-07-30 19:23     ` David Wysochanski
2020-07-30 19:59       ` David Wysochanski [this message]
2020-07-30 20:03       ` David Howells
2020-07-30 21:07         ` David Wysochanski
2020-07-29 14:12 ` [RFC PATCH v2 14/14] NFS: Allow NFS use of new fscache API in build Dave Wysochanski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALF+zOn9tSft_QkPaJ7w8v_OLTfon+acUB_W9MSb8EEMQGc94w@mail.gmail.com \
    --to=dwysocha@redhat.com \
    --cc=anna.schumaker@netapp.com \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).