> On Sep 1, 2017, at 4:09 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: > > On Fri, Sep 01, 2017 at 04:02:48PM -0400, Olga Kornievskaia wrote: >> >>> On Sep 1, 2017, at 3:53 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: >>> >>> On Fri, Sep 01, 2017 at 03:48:33PM -0400, Olga Kornievskaia wrote: >>>> On Fri, Sep 1, 2017 at 3:41 PM, J. Bruce Fields <bfields@xxxxxxxxxx> wrote: >>>>> - what currently happens if you try to copy across krb5 mounts? >>>> >>>> No GSSv3 is included in these patches. The destination server will >>>> mount the source server using auth_sys. >>> >>> Assuming that doesn't work--how is the failure handled? >> >> If mount fails? Destination server returns an error in COPY (whatever >> vfs_kern_mount can return). Client calls generic nfs4_handle_exception() >> but it’s probably a kind of error it doesn’t handle so it’ll be translated to EIO. >> What kind of error are you thinking about? > > I just want to make sure that copy_file_range() caller knows what to do > when it encounters this situation. > > The typical application probably wants to fall back on a read-write loop > in the case inter-server copy isn't supported between the given mounts? > > EIO doesn't sound like the most helpful error to me, but whatever error > it is, it should be documented in the copy_file_range man page so that > callers know how to check for this case. On the client side, if we were to receive an error code that signified a connection problem, then COPY implementation could map that to something that would trigger the VFS to just fallback to do_splice. However, I couldn’t find any errors in 15.1 from rfc5661 or 11.1 from 7862 that could mean connection errors (that’s typically RPC errors right). -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
