All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: David Howells <dhowells@redhat.com>, linux-cachefs@redhat.com
Cc: Anna Schumaker <anna.schumaker@netapp.com>,
	Steve French <sfrench@samba.org>,
	Dominique Martinet <asmadeus@codewreck.org>,
	David Wysochanski <dwysocha@redhat.com>,
	Ilya Dryomov <idryomov@gmail.com>,
	Jeffle Xu <jefflexu@linux.alibaba.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org,
	linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 18/19] netfs: Keep track of the actual remote file size
Date: Wed, 09 Mar 2022 15:45:02 -0500	[thread overview]
Message-ID: <2ebfd2f772ceef605896e58bbd0e733e1413ff71.camel@kernel.org> (raw)
In-Reply-To: <164678219305.1200972.6459431995188365134.stgit@warthog.procyon.org.uk>

On Tue, 2022-03-08 at 23:29 +0000, David Howells wrote:
> Provide a place in which to keep track of the actual remote file size in
> the netfs context.  This is needed because inode->i_size will be updated as
> we buffer writes in the pagecache, but the server file size won't get
> updated until we flush them back.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: linux-cachefs@redhat.com
> 
> Link: https://lore.kernel.org/r/164623013727.3564931.17659955636985232717.stgit@warthog.procyon.org.uk/ # v1
> ---
> 
>  include/linux/netfs.h |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/linux/netfs.h b/include/linux/netfs.h
> index 8458b30172a5..c7bf1eaf51d5 100644
> --- a/include/linux/netfs.h
> +++ b/include/linux/netfs.h
> @@ -126,6 +126,7 @@ struct netfs_i_context {
>  #if IS_ENABLED(CONFIG_FSCACHE)
>  	struct fscache_cookie	*cache;
>  #endif
> +	loff_t			remote_i_size;	/* Size of the remote file */
>  };
>  
>  /*
> @@ -324,6 +325,21 @@ static inline void netfs_i_context_init(struct inode *inode,
>  
>  	memset(ctx, 0, sizeof(*ctx));
>  	ctx->ops = ops;
> +	ctx->remote_i_size = i_size_read(inode);
> +}
> +
> +/**
> + * netfs_resize_file - Note that a file got resized
> + * @inode: The inode being resized
> + * @new_i_size: The new file size
> + *
> + * Inform the netfs lib that a file got resized so that it can adjust its state.
> + */
> +static inline void netfs_resize_file(struct inode *inode, loff_t new_i_size)
> +{
> +	struct netfs_i_context *ctx = netfs_i_context(inode);
> +
> +	ctx->remote_i_size = new_i_size;
>  }
>  
>  /**
> 
> 

This seems like something useful, but I wonder if it'll need some sort
of serialization vs. concurrent updates. Can we assume that netfs itself
will never call netfs_resize_file?

Ceph already has some pretty complicated size tracking, since it can get
async notifications of size changes from the MDS. We'll have to consider
how to integrate this with what it does. Probably this will replace one
(or more?) of its fields.

We may need to offer up some guidance wrt locking.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2022-03-09 20:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 23:24 [PATCH v2 00/19] netfs: Prep for write helpers David Howells
2022-03-08 23:25 ` [PATCH v2 01/19] fscache: export fscache_end_operation() David Howells
2022-03-09 15:26   ` Jeff Layton
2022-03-10  1:40     ` JeffleXu
2022-03-08 23:25 ` [PATCH v2 02/19] netfs: Generate enums from trace symbol mapping lists David Howells
2022-03-09 15:30   ` Jeff Layton
2022-03-09 15:49   ` David Howells
2022-03-09 18:39     ` Jeff Layton
2022-03-08 23:25 ` [PATCH v2 03/19] netfs: Rename netfs_read_*request to netfs_io_*request David Howells
2022-03-09 15:31   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 04/19] netfs: Finish off rename of netfs_read_request to netfs_io_request David Howells
2022-03-09 15:34   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 05/19] netfs: Split netfs_io_* object handling out David Howells
2022-03-09 15:44   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 06/19] netfs: Adjust the netfs_rreq tracepoint slightly David Howells
2022-03-09 15:45   ` Jeff Layton
2022-03-08 23:26 ` [PATCH v2 07/19] netfs: Trace refcounting on the netfs_io_request struct David Howells
2022-03-08 23:27 ` [PATCH v2 08/19] netfs: Trace refcounting on the netfs_io_subrequest struct David Howells
2022-03-08 23:27 ` [PATCH v2 09/19] netfs: Adjust the netfs_failure tracepoint to indicate non-subreq lines David Howells
2022-03-08 23:28 ` [PATCH v2 10/19] netfs: Refactor arguments for netfs_alloc_read_request David Howells
2022-03-08 23:28 ` [PATCH v2 11/19] netfs: Change ->init_request() to return an error code David Howells
2022-03-09 16:52   ` Jeff Layton
2022-03-08 23:28 ` [PATCH v2 12/19] netfs: Add a netfs inode context David Howells
2022-03-09 18:22   ` Jeff Layton
2022-03-09 19:23   ` David Howells
2022-03-09 19:46     ` Jeff Layton
2022-03-08 23:29 ` [PATCH v2 13/19] netfs: Add a function to consolidate beginning a read David Howells
2022-03-09 19:26   ` Jeff Layton
2022-03-09 22:08   ` David Howells
2022-03-08 23:29 ` [PATCH v2 14/19] netfs: Prepare to split read_helper.c David Howells
2022-03-08 23:29 ` [PATCH v2 15/19] netfs: Rename read_helper.c to io.c David Howells
2022-03-08 23:29 ` [PATCH v2 16/19] netfs: Split fs/netfs/read_helper.c David Howells
2022-03-09 20:27   ` Jeff Layton
2022-03-08 23:29 ` [PATCH v2 17/19] netfs: Split some core bits out into their own file David Howells
2022-03-08 23:29 ` [PATCH v2 18/19] netfs: Keep track of the actual remote file size David Howells
2022-03-09 20:45   ` Jeff Layton [this message]
2022-03-09 22:27   ` David Howells
2022-03-08 23:30 ` [PATCH v2 19/19] afs: Maintain netfs_i_context::remote_i_size David Howells
2022-03-09 21:12   ` Jeff Layton
2022-03-09 22:35   ` David Howells

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=2ebfd2f772ceef605896e58bbd0e733e1413ff71.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=anna.schumaker@netapp.com \
    --cc=asmadeus@codewreck.org \
    --cc=ceph-devel@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dwysocha@redhat.com \
    --cc=idryomov@gmail.com \
    --cc=jefflexu@linux.alibaba.com \
    --cc=linux-afs@lists.infradead.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sfrench@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.