Return-Path: Received: from bombadil.infradead.org ([65.50.211.133]:42714 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111AbdFQPJm (ORCPT ); Sat, 17 Jun 2017 11:09:42 -0400 Date: Sat, 17 Jun 2017 08:09:38 -0700 From: Christoph Hellwig To: Olga Kornievskaia Cc: Christoph Hellwig , "J. Bruce Fields" , Andreas Dilger , Olga Kornievskaia , "linux-fsdevel@vger.kernel.org" , linux-nfs Subject: Re: [PATCH 1/1] [RFC] 64bit copy_file_range system call Message-ID: <20170617150938.GA28885@infradead.org> References: <20170614170653.58083-1-kolga@netapp.com> <20170615081502.GA10599@infradead.org> <20170616173630.GE12030@fieldses.org> <20170617100309.GA9469@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Sat, Jun 17, 2017 at 08:42:54AM -0400, Olga Kornievskaia wrote: > > > On Jun 17, 2017, at 6:03 AM, Christoph Hellwig wrote: > > > > On Fri, Jun 16, 2017 at 01:36:30PM -0400, J. Bruce Fields wrote: > >> It makes a difference in the clone case, doesn't it? (Though I'd think > >> best there would be a special "copy to end of file" value.) > > > > Clones uses a 0 length as "whole" file. Both for the NFS operation > > and the Linux ioctl. > > Does that actually work? There is check vfs_copy_file_range() Please re-read the above sentence. I'm talking about NFS clone and IOC_CLONE_RANGE, not copy_file_range. copy_file_range had to follow the NFS semantics that don't have the special 0 case.