Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CABV8kRw_jGxPqWc68Bj-uP_hSrKO0MmShOmtuzGQA2W3WHyCrg@mail.gmail.com>
 <CAOQ4uxhPKR34cXvWfF49z8mTGJm+oP2ibfohsXNdY7tXaOi4RA@mail.gmail.com>
 <CABV8kRxVA0j2qLkyWx+vULh2DxK2Ef4nPk-zXCikN8XmdBOFgQ@mail.gmail.com>
 <CAOQ4uxh2KKwORLC+gWEF=mWzBa3Kh4A4HgRoiad5N5qu06xjcg@mail.gmail.com> <CABV8kRxsGm2-RLsuWPQGc82=6+x8v8FtV0=a6MQS=Nt-Pv3V9A@mail.gmail.com>
In-Reply-To: <CABV8kRxsGm2-RLsuWPQGc82=6+x8v8FtV0=a6MQS=Nt-Pv3V9A@mail.gmail.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Tue, 14 Apr 2020 06:00:17 +0300
Message-ID: <CAOQ4uxj1csY-Vn2suFZMseEZgvAZzhQ82TR+XtDRQ=cOzwvzzw@mail.gmail.com>
Subject: Re: Same mountpoint restriction in FICLONE ioctls
To:     Keno Fischer <keno@juliacomputing.com>
Cc:     linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Miklos Szeredi <mszeredi@redhat.com>,
        linux-xfs <linux-xfs@vger.kernel.org>,
        CIFS <linux-cifs@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Olga Kornievskaia <kolga@netapp.com>,
        Steve French <smfrench@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Mon, Apr 13, 2020 at 10:40 PM Keno Fischer <keno@juliacomputing.com> wrote:
>
> > You make it sound like the heuristic decision must be made
> > *after* trying to clone, but it can be made before and pass
> > flags to the kernel whether or to fallback to copy.
>
> True, though I simplified slightly. There's other things we try
> first if the clone fails, like creating a hardlink. If cloning fails,
> we also often only want to copy a part of the file (again
> heuristically, whether more than what the program asked
> for will be useful for debugging)

Fair enough.

>
> > copy_file_range(2) has an unused flags argument.
> > Adding support for flags like:
> > COPY_FILE_RANGE_BY_FS
> > COPY_FILE_RANGE_BY_KERNEL
>
> That would solve it of course, and I'd be happy with that
> solution, but it seems like we'd end up with just another
> spelling for the cloning ioctls then that have subtly different
> semantics.
>

Yeh. Another spelling is a common way to change behavior.
In fact, it is the only way if you want to avoid changing behavior
of existing application.

Generally speaking, syscall interface is an improvement over ioctl
interface. Flags like:
COPY_FILE_RANGE_REFLINK
COPY_FILE_RANGE_NO_XDEV
along with proper documentation, can help make the change of behavior
explicit. The flags mentioned above would describe the existing
FICLONERANGE semantics.

But the thing is that the above is not just a fancy maneuver for relaxing the
same mnt restriction of FICLONERANGE.
I believe that enhancing the semantics of copy_file_range(2) has benefits
beyond your use case.
copy tools could make use of nfs/cifs server side copy without falling back
to kernel copy.

Thanks,
Amir.