On Fri, Oct 26, 2018 at 11:44 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > > > > On Oct 26, 2018, at 11:39 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > > > On Fri, Oct 26, 2018 at 11:04 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > >> > >> > >> > >>> On Oct 26, 2018, at 8:54 AM, Olga Kornievskaia <aglo@xxxxxxxxx> 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 > > >
