On 29 Nov 2023, at 8:20, Dan Aloni wrote: > On 2023-11-07 08:46:54, Benjamin Coddington wrote: >> Hi Dan, >> >> On 5 Nov 2023, at 10:48, Dan Aloni wrote: >> >>> Hi, >>> >>> On Linux v6.6-14500-g1c41041124bd, I added a sysfs file for debugging >>> `/sys/kernel/debug/sunrpc/rpc_clnt/*/info`, and noticed that when >>> passing the following mount options: `soft,timeo=50,retrans=16,vers=3`, >>> NFSACL and NSM seem to take the defaults from somewhere else (xprt). >>> Specifically, locking operation behave as if in a hard mount with >>> these mount options. >>> >>> Is it intentional? >> >> Yes, it usually is intentional. The various rpc clients that make parts of >> NFS work don't all inherit the mount flags due to reasons about how the >> system should behave as a whole. I think that you can find usually find the >> reasoning the git logs around "struct rpc_create_args". >> >> Are you getting a system hung up in a lock operation? > > Actually my concern is the NFSACL prog. With `cl_softrtrt == 1` and > `to_initval == to_maxval`, does it mean retires will not happen > regardless of `to_retries` and `to_increment`? Possibly? I'm not exactly certain of what should happen in that case. > I encountered a situation where the NFSACL program did not retry but > could have had, whereas NFS3 did successfully. Not sure regarding NSM, > but it seems to me that it would make sense at least for NFSACL to > behave the same as NFS3. I agree, but I could be missing something -- maybe its a bug. There's the sunrpc:rpc_timeout_status tracepoint that might be helpful. If you turn that up can you see rpc_check_timeout() getting called from call_transmit_status()? Sorry, I know this isn't a lot of help so far. Ben
