DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06CC02082B
MIME-Version: 1.0
References: <CAN-5tyEn+mM8ucuPXawN9L57XyGHUQHNL6Ddic5TFdXYTY2bSg@mail.gmail.com>
 <6CA0FBE4-6B7C-4D05-BE1E-AB3BEDD90171@oracle.com>
In-Reply-To: <6CA0FBE4-6B7C-4D05-BE1E-AB3BEDD90171@oracle.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Fri, 26 Oct 2018 11:39:38 -0400
Message-ID: <CAN-5tyE25JYUbnhvRD32_ZxyALdXd+emy2qK315DeXb+DgLn1Q@mail.gmail.com>
Subject: Re: copy offload support and absent file system
To:     Chuck Lever <chuck.lever@oracle.com>
Cc:     linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Fri, Oct 26, 2018 at 11:04 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>
> > On Oct 26, 2018, at 8:54 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > Hi Chuck,
> >
> > In the context of doing a copy between different "types" of
> > filesystems, it was pointed out to me that NFS has many types:
> > nfs4_fs_type, nfs4_remote_fs_type, nfs4_remote_referral_fs_type,
> > nfs4_referral_fs_type. So doing a simple check that fs type of "in"
> > and "out" might not be sufficient. Do you see any issues allowing a
> > copy offload between different types? Basically checking that "in" and
> > "out" descriptions come from any of the these types?
>
> I'm no expert... so what follows is an uninformed opinion.

I was wondering if there was anything different about the
migrated/replicated filesystem that maybe say they are typically
read-only and thus doing a copy there wouldn't be appropriate. But it
sounds like you don't see anything special about doing a copy from
nfs4_fs_type to say nfs_remote_fs_type?

> All of these are NFSv4 file systems. But I don't think that's an
> adequate check (it's necessary, but not sufficient).


> The minor version of the mount point has to be 2 or higher, and
> the client must confirm that the mounted server supports copy
> offload (because all NFSv4.2 features are OPTIONAL).

I agree that we should check for 4.2 versioning but the latter I don't
think is necessary, as the COPY call will just gets not supported
error (we already have the capability check for CAP_COPY inside of
nfs42_proc_copy , just in case we already sent one copy and then
negated the capabilities).

>
>
> --
> Chuck Lever
>
>
>