>>>>> "BC" == Benjamin Coddington <bcodding@xxxxxxxxxx> writes: BC> Hi Michael, can you clarify what you mean by "client machine locks BC> up"? Are you receiving reports of a hung task in the kernel logs? I'll chime in to say that I'm seeing something which may potentially related that I haven't been able to spend the time to track down properly. Basically, I can make NFS hang just by editing a file with vim on the client. When I attempt to write the file, the vim process goes into the 'D' state, probably trying to do some sort of locking (as I have a lot of stuff running inside of vim). I think this may require that you not have write permissions on the directory containing the file I'm editing, so that vim is forced to write backups or do locking or something back in my NFS-mounted home directory. Once this happens, the server actually gets into an odd state. I have seen vim instances running on the server hang (probably trying to lock a file) until the client is rebooted. And even after the client is rebooted, it still can't mount anything from the server. Instead the mount call itself just hangs, along with a kernel thread named "[172.21.86.85-ma]". This state will persist until the server itself is rebooted. Server: Fedora 26, kernel 4.12.9 (need to reboot into 4.12.13 soon). Clients: Fedora 25, various 4.11.X and 4.12.X. All mounts are via NFS4.2/krb5i. I think this might have come in when I updated this server to something in the 4.12 kernel series but I'm not completely sure at this point. - J< -- 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
