copy offload support and absent file system

copy offload support and absent file system

[Olga Kornievskaia]

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?

Thank you.

Re: copy offload support and absent file system

[Chuck Lever]

> 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.

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).


--
Chuck Lever

Re: copy offload support and absent file system

[Olga Kornievskaia]

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
>
>
>

Re: copy offload support and absent file system

[Chuck Lever]

> On Oct 26, 2018, at 11:39 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> 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?

If I recall correctly the distinction between these "types" is
the way they are attached to the client's filesystem namespace.
I don't believe that would have any impact on whether copy
offload is supported or not.


>> 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).

The COPY call could also return EROFS if the destination filesystem
is a read-only replica.

--
Chuck Lever

Re: copy offload support and absent file system

[Olga Kornievskaia]

On Fri, Oct 26, 2018 at 11:44 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
>
>
> > On Oct 26, 2018, at 11:39 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
> >
> > 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?
>
> If I recall correctly the distinction between these "types" is
> the way they are attached to the client's filesystem namespace.
> I don't believe that would have any impact on whether copy
> offload is supported or not.
>
>
> >> 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).
>
> The COPY call could also return EROFS if the destination filesystem
> is a read-only replica.

In such case, I would hope that the OPEN of the destination file for
writing would fail and we won't even get to the COPY.

>
> --
> Chuck Lever
>
>
>