Zhitao Li

There are some threads named "svc_xxx" in syscall(). They are trapped into a loop, which may result from our customized logic. GDB backtraces ``` (gdb) t 53 [Switching to thread...

> (Ganesha does actual client work in the svc_* threads, which are created by NTIRPC) If some thread named "svc_xxx" trapped into an indefinite loop, then will the data received...

Thanks for your reply. In this case, there is one connection that does not move forward. Any new connections can work as expected.

This is very possible. I will check our sfs code. By the way, I still have a question. There are threads waiting for events. And there is event(new data) on...

Solved after recover from sfs-client waiting. We learned that "svc_" threads can not block by FSAL operations(->sfs-client). Thanks for your help @dang @ffilz

I try to understand the thread model by implementation of libntirpc as follows: 1. There is a work_pool which handles almost all work of RPC, including new connections, send/recv/handling data...

> Also, if you have a FSAL operation that is blocking for a long time with one of the mdcache locks held, we should look at what you are trying...

Thanks for your reply. I admit that there are locking issues because of our bugs. **I'm confused about how many threads are watching events for one the established connection**. If...

In this case, if I mount the export with the same options again, the RECV-Q of following connection in the nfs-ganesha will increase about 180 bytes. So **instead of client...

> There is a dynamic-size work_pool which handles almost all work of RPC, including new connections, send/recv/handling data by the connections. There are some event-channel threads(default 5) dedicated to watch...