Hi. Suppose I have a mobile client such as a notebook computer which changes networks from time to time - e.g. when "docked" it uses a wired network, but when I "undock" it uses a wireless network. And as I move around it might change from one wireless network to another. Is it at all reasonable to expect that I could have an NFS mounted filesystem that continues to work across all of those changes? If we just assume NFSv3 and ignore locking for the moment, then this seems to work quite well if you use UDP, but fails badly if you use TCP. This is because the connected socket holds on to the old source address. I think that the only way to get the client to close and re-open the socket would be to wait for 5 minutes with no IO requests. But that would be hard to ensure. Any attempt to access any file will trigger a request which will keep retrying which will keep the socket active, so the client won't close it.... It doesn't seem to work anyway. The RPC client appears to try to connect from the same source IP address, though I haven't checked the code to be sure of this. Would it be worthwhile/practical to have a 'remount' mount option to request that the socket be closed and re-opened? If there were any active locks, there is probably nothing useful that can be done for them. Unless the client manages to send a NOTIFY to the server before changing IP address, the server will never drop the locks. Maybe "-o remount,reopen" would only work if "-o nolocks" were in force. It's not an ideal solution, but it might be better than the current situations? I'm not sure whether NFSv4 makes this easier or harder. Can you continue a client session (SET_CLIENTID) from a different IP address? Can you change the callback address for a CLIENT once it is created? For now, I think the options are to use UDP (which has it's own problems) or to for an unmount (--lazy) when the client IP address changes. Thoughts? Thanks, NeilBrown -- 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
