Re: [RFC v1 00/17] NFSD support for inter+async COPY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 01, 2017 at 04:34:16PM -0400, Olga Kornievskaia wrote:
> 
> > 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. 

Oh, right.

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

Looking at 7862....  Shouldn't these sorts of cases result in one of the
new errors described in
https://tools.ietf.org/html/rfc7862#section-11.1.2 ?

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



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux