At 02:59 PM 10/17/2008, Marc Eshel wrote: >linux-nfs-owner@xxxxxxxxxxxxxxx wrote on 10/17/2008 10:44:54 AM: > >> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> >> Requests longer than a page are still not deferred, so large writes that >> trigger upcalls still get an ERR_DELAY. OK, probably no big deal. >> >> I don't think we can apply this until we have some way to track the >> number and size of deferred requests outstanding and fall back on >> ERR_DELAY if it's too much. > >But I thought that the problem here is that the Linux NFS client doesn't >handle this return code properly. Definitely this is an issue. Early clients do one of two things, they either pass the error back to the application, or they enter a buzz loop resending the operation with no delay. Later clients back off, but for a constant five seconds. Either way, the server is generally better off gritting its teeth and completing the operation. Blocking server threads is drastic, but in effect it will stall the client queues and "push back". The issue on Linux is the small number of nfsd contexts involved. It could lead to significant issues possibly including DOS attack. Dropping connections (judiciously) could be used instead of blocking the last few threads, though even that will have consequences. The easy way to test all this is decorate /etc/exports with lots of names, then break the nameservice and start sending requests from many new clients. It's very hard to get it all right. Tom. -- 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
