All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niels de Vos <ndevos@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Marcin Sulikowski <marcin.k.sulikowski@gmail.com>
Subject: Re: [PATCH v2] fuse: add support for copy_file_range()
Date: Fri, 29 Jun 2018 14:16:30 +0200	[thread overview]
Message-ID: <20180629121630.GS2345@ndevos-x270> (raw)
In-Reply-To: <20180627084648.16892-1-ndevos@redhat.com>

On Wed, Jun 27, 2018 at 10:46:48AM +0200, Niels de Vos wrote:
> There are several FUSE filesystems that can implement server-side copy
> or other efficient copy/duplication/clone methods. The copy_file_range()
> syscall is the standard interface that users have access to while not
> depending on external libraries that bypass FUSE.
> 
> Signed-off-by: Niels de Vos <ndevos@redhat.com>

NACK on this by myself, see reason further below.

> 
> ---
> v2: return ssize_t instead of long
> ---
>  fs/fuse/file.c            |  65 +++++++++++++++++++++++
>  fs/fuse/fuse_i.h          |   3 ++
>  include/uapi/linux/fuse.h | 106 ++++++++++++++++++++++----------------
>  3 files changed, 130 insertions(+), 44 deletions(-)
...
> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> index 92fa24c24c92..77330fa510f1 100644
> --- a/include/uapi/linux/fuse.h
> +++ b/include/uapi/linux/fuse.h
...
> @@ -792,4 +796,18 @@ struct fuse_lseek_out {
>  	uint64_t	offset;
>  };
>  
> +struct fuse_copy_file_range_in {
> +	uint64_t	fh_in;
> +	uint64_t	off_in;

It seems that libfuse has the expectation of having access to the nodeid
when a file-descriptor is passed to userspace.

>From Marcin Sulikowski in https://github.com/libfuse/libfuse/pull/259:

> There is a caveat though – the kernel module change proposed in
> https://lkml.org/lkml/2018/6/27/114 provides only ino_in argument
> because that is passed in the request's header (args.in.h.nodeid =
> ff_in->nodeid; in fs/fuse/fuse.c in the kernel) whereas ino_out is not
> given by the kernel to the userspace implementation. Isn't this an
> oversight in the kernel module? The lack of the inode number would
> make it impossible to create high-level interface which follows the
> libfuse's convention where the high-level callbacks are given paths to
> files which are to be modified.

So, the next version of this patch will add nodeid_out to the struct.

Niels


> +	uint64_t	fh_out;
> +	uint64_t	off_out;
> +	uint64_t	len;
> +	uint32_t	flags;
> +};
> +
> +struct fuse_copy_file_range_out {
> +	uint32_t	size;
> +	uint32_t	padding;
> +};
> +
>  #endif /* _LINUX_FUSE_H */
> -- 
> 2.17.1
> 

WARNING: multiple messages have this Message-ID (diff)
From: Niels de Vos <ndevos@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>, linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
	Marcin Sulikowski <marcin.k.sulikowski@gmail.com>
Subject: Re: [PATCH v2] fuse: add support for copy_file_range()
Date: Fri, 29 Jun 2018 14:16:30 +0200	[thread overview]
Message-ID: <20180629121630.GS2345@ndevos-x270> (raw)
In-Reply-To: <20180627084648.16892-1-ndevos@redhat.com>

On Wed, Jun 27, 2018 at 10:46:48AM +0200, Niels de Vos wrote:
> There are several FUSE filesystems that can implement server-side copy
> or other efficient copy/duplication/clone methods. The copy_file_range()
> syscall is the standard interface that users have access to while not
> depending on external libraries that bypass FUSE.
> 
> Signed-off-by: Niels de Vos <ndevos@redhat.com>

NACK on this by myself, see reason further below.

> 
> ---
> v2: return ssize_t instead of long
> ---
>  fs/fuse/file.c            |  65 +++++++++++++++++++++++
>  fs/fuse/fuse_i.h          |   3 ++
>  include/uapi/linux/fuse.h | 106 ++++++++++++++++++++++----------------
>  3 files changed, 130 insertions(+), 44 deletions(-)
...
> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> index 92fa24c24c92..77330fa510f1 100644
> --- a/include/uapi/linux/fuse.h
> +++ b/include/uapi/linux/fuse.h
...
> @@ -792,4 +796,18 @@ struct fuse_lseek_out {
>  	uint64_t	offset;
>  };
>  
> +struct fuse_copy_file_range_in {
> +	uint64_t	fh_in;
> +	uint64_t	off_in;

It seems that libfuse has the expectation of having access to the nodeid
when a file-descriptor is passed to userspace.

From Marcin Sulikowski in https://github.com/libfuse/libfuse/pull/259:

> There is a caveat though – the kernel module change proposed in
> https://lkml.org/lkml/2018/6/27/114 provides only ino_in argument
> because that is passed in the request's header (args.in.h.nodeid =
> ff_in->nodeid; in fs/fuse/fuse.c in the kernel) whereas ino_out is not
> given by the kernel to the userspace implementation. Isn't this an
> oversight in the kernel module? The lack of the inode number would
> make it impossible to create high-level interface which follows the
> libfuse's convention where the high-level callbacks are given paths to
> files which are to be modified.

So, the next version of this patch will add nodeid_out to the struct.

Niels


> +	uint64_t	fh_out;
> +	uint64_t	off_out;
> +	uint64_t	len;
> +	uint32_t	flags;
> +};
> +
> +struct fuse_copy_file_range_out {
> +	uint32_t	size;
> +	uint32_t	padding;
> +};
> +
>  #endif /* _LINUX_FUSE_H */
> -- 
> 2.17.1
> 

  reply	other threads:[~2018-06-29 12:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-27  7:45 [PATCH] fuse: add support for copy_file_range() Niels de Vos
2018-06-27  8:20 ` kbuild test robot
2018-06-27  8:25 ` kbuild test robot
2018-06-27  8:46 ` [PATCH v2] " Niels de Vos
2018-06-29 12:16   ` Niels de Vos [this message]
2018-06-29 12:16     ` Niels de Vos
2018-06-29 12:53     ` [PATCH v3] " Niels de Vos
2018-08-06 10:46       ` Niels de Vos
2018-08-07 12:02       ` Miklos Szeredi
2018-08-21 10:12         ` Niels de Vos
2018-08-21 12:36           ` [PATCH v4] " Niels de Vos
2018-10-01  9:21             ` Miklos Szeredi

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=20180629121630.GS2345@ndevos-x270 \
    --to=ndevos@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.k.sulikowski@gmail.com \
    --cc=miklos@szeredi.hu \
    /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.