From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:41244 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754720AbeF2MQc (ORCPT ); Fri, 29 Jun 2018 08:16:32 -0400 Date: Fri, 29 Jun 2018 14:16:30 +0200 From: Niels de Vos To: Miklos Szeredi , linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Marcin Sulikowski Subject: Re: [PATCH v2] fuse: add support for copy_file_range() Message-ID: <20180629121630.GS2345@ndevos-x270> References: <20180627074534.7307-1-ndevos@redhat.com> <20180627084648.16892-1-ndevos@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180627084648.16892-1-ndevos@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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 >