Re: [PATCH v3 015/114] nfsd: Allow struct nfsd4_compound_state to cache the nfs4_client

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

 



On Thu, 3 Jul 2014 09:11:40 -0700
Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

> On Thu, Jul 03, 2014 at 11:32:08AM -0400, J. Bruce Fields wrote:
> > > > > +	struct nfs4_client *found;
> > > > > +
> > > > > +	if (cstate->clp) {
> > > > > +		found = cstate->clp;
> > > > > +		if (!same_clid(&found->cl_clientid, clid))
> > > > > +			return nfserr_stale_clientid;
> > > > 
> > > > That's new behavior, isn't it?
> > > > 
> > > 
> > > Yeah, I suppose it is, but it's hard to understand a valid use-case for
> > > sending multiple ops in a compound with different clientids. Certainly
> > > no well-behaved client would do that, would it? (Hmm, that might be an
> > > interesting pynfs test, come to think of it).
> > 
> > We could ask for a clarification in 3530bis if there's not already
> > something there that clearly forbids this, but I'm not sure if it's even
> > worth it.
> 
> Or just handle it and be done with me.  After all we'd just need to put
> the existing client, and store the new one in the cstate.
> 

Meh, ok... I suppose there's no harm in doing that and since that's the
behavior that was there before, we should probably go with it for the
v4.0 case. I'll have the next iteration do that instead.

Thanks,
-- 
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
--
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