Re: nfsd: delegation conflicts between NFSv3 and NFSv4 accessors

[bfields@fieldses.org (J. Bruce Fields)]

On Mon, Mar 13, 2017 at 01:12:32PM -0400, Chuck Lever wrote:
> > On Mar 13, 2017, at 12:33 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > Yes. I'm just not sold that what you're proposing would be any better
> > than what we have for the vast majority of people. It might be, but I
> > don't think that's necessarily the case.
> 
> In other words, both of you are comparing my use case with
> a counterfactual. That doesn't seem like a fair fight.

There's always a bias towards existing behavior.

> Can you demonstrate a specific use case where not offering
> a delegation during mixed NFSv3 and NFSv4 access is a true
> detriment? (I am open to hearing about it).

I'd look for a read-mostly workload with frequent opens and
closes--maybe libraries or config files that every executable opens at
startup?

> What happens when an NFSv3 client sends an NLM LOCK on a
> delegated file? I assume the correct response is for the
> server to return NLM_LCK_BLOCKED, recall the delegation, and
> then call the client back when the delegation has been
> returned. Is that known to work?

I don't currently have a test for that, and from looking at the code I'm
not confident it's correct.

Looks like the call chain is:

	nlmsvc_proc_lock->
	  nlmsvc_retrieve_args->
	    nlm_lookup_file->
	      fopen = nlm_open->
	        nfsd_open->nfsd_open_break_lease

And I'd expect that to return EWOULDBLOCK.  But nfsd_open is getting
called just with MAY_LOCK, and I think it needs MAY_READ or _WRITE to
recognize conflicts correctly.

And then if it did hit a conflict it would return EWOULDBLOCK, but it
looks like that ends up as nlm_lck_denied_nolocks, which is totally
unhelpful.

It's possible I'm missing something.  Obviously it needs testing.

> There are other cases where context switching an nfsd would be
> useful. For example, inserting an opportunity for nfsd_write
> to perform transport reads (after having allocated pages in
> the right file) could provide some benefits by reducing data
> copies and page allocator calls.

For now I think we can just live with threads blocking briefly--as you
say, we already do for disk.  Though if a slow client could cause that
rdma read to block too long then we'd need a maximum timeout.

--b.