Hi Trond- There's some internal testing going on here where a Linux NFS client mounts a server with NFSv4.1, then the server is rebooted with older software that supports only NFSv4.0. We're looking at how the client responds to this odd corner case. Active I/O system calls on that mount complete with "Protocol not supported". I wasn't sure if this was a permitted error code for write(2), stat(2), or getdents(3). Another question is what happens when the server reboots again and it supports NFSv4.1 again. Our testing shows the mount starts to work again. But we're wondering if it's possible for open or lock state to remain on the client after the first reboot, and if so, is there any guarantee that state can be properly recovered by the client when the server supports NFSv4.1 again. Our feeling is that it can't. Perhaps the client should make that mount point unusable after the first server reboot? This feels like a state recovery edge condition, perhaps not covered by RFC 5661 and newer. -- Chuck Lever -- 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
