On Mon, Mar 13, 2017 at 01:12:32PM -0400, Chuck Lever wrote: > > On Mar 13, 2017, at 12:33 PM, Jeff Layton <jlayton@xxxxxxxxxx> 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. -- 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
