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
Hi Neil,
If you have running over IPv6, you can use Mobile IPv6 (configure
IPv6_MIP6)
to make this work over TCP. I have never tried it, but theoretically it
should
work. Mobile IP will fool the TCP layer (and other ULP's) onwards by
passing
the "home" network address while using the new network address internally
at
IP layer for communication (both sends and recvs).
- KK
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Neil Brown wrote:
>
> 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.
This is quite a common scenario these days.
> Is it at all reasonable to expect that I could have an NFS mounted
> filesystem that continues to work across all of those changes?
I think it is reasonable to expect with the changing network paradigm of
mobile computing. Successful protocols/implementations always have
adapted themselves to the changing (network) needs :)
> 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?
or better name would be 'reconnect'?
> 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?
Definitely, it can make mobile clients life easier. And it looks to me
that all of these can be done at the userspace itself.
> 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?
I think 'nolock' and 'nfs4' can't be used together and nfs4 always will
enable locking.
Thanks,
--
Suresh Jayaraman
Suresh Jayaraman wrote:
> Neil Brown wrote:
>
>> 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.
>>
>
> This is quite a common scenario these days.
>
>
>> Is it at all reasonable to expect that I could have an NFS mounted
>> filesystem that continues to work across all of those changes?
>>
>
> I think it is reasonable to expect with the changing network paradigm of
> mobile computing. Successful protocols/implementations always have
> adapted themselves to the changing (network) needs :)
>
The other place to address this is in the networking layer itself. If I
remember correctly, there is support in IPV6 for "mobile IP" which might
allow you to do this:
http://www.ietf.org/rfc/rfc2002.txt
I have no idea how much of this made it into working systems,
ric
>
>> 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?
>>
>
> or better name would be 'reconnect'?
>
>
>> 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?
>>
>
> Definitely, it can make mobile clients life easier. And it looks to me
> that all of these can be done at the userspace itself.
>
>
>> 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?
>>
>
> I think 'nolock' and 'nfs4' can't be used together and nfs4 always will
> enable locking.
>
>
> Thanks,
>
>
Neil Brown wrote:
> 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.
Could this possibly be handled by some type of user-level connection manager that would be able to deal with the changing of a server's IP 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.
Again, this is where I think a connection manager could help... The kernel could do a "this server is broken give me another please" up-call and the CM could do all the needed host-to-address translation, making sure the IP address that is passed down a valid and working address...
Continuing with this theory... this might be a cheap and dirty way of getting redundant or failover mount for v2/v3... with read-only mounts of course...
>
> Would it be worthwhile/practical to have a 'remount' mount option to
> request that the socket be closed and re-opened?
Only if we could teach autofs to do this... otherwise it should be
auto-magically... imho..
>
> 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?
Or read-only mounts... Meaning, we start with read-only and then move on to read/write mounts..
>
> 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?
I would think easier since there is less traffic between the server and client due to delegations...
my two cents...
steved.
Steve Dickson wrote:
Could this possibly be handled by some type of user-level connection
manager that would be able to deal with the changing of a server's IP
address?
This shouldn't be necessary. The nfs client already deals successfully with
the case where a tcp connection is closed unexpectedly. All that's needed
is to make sure the connection closes when the client moves. If the network
layer doesn't do this already, it should.
On Wednesday September 24, [email protected] wrote:
> Suresh Jayaraman wrote:
> > Neil Brown wrote:
> >
> >> 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.
> >>
> >
> > This is quite a common scenario these days.
> >
> >
> >> Is it at all reasonable to expect that I could have an NFS mounted
> >> filesystem that continues to work across all of those changes?
> >>
> >
> > I think it is reasonable to expect with the changing network paradigm of
> > mobile computing. Successful protocols/implementations always have
> > adapted themselves to the changing (network) needs :)
> >
>
> The other place to address this is in the networking layer itself. If I
> remember correctly, there is support in IPV6 for "mobile IP" which might
> allow you to do this:
>
> http://www.ietf.org/rfc/rfc2002.txt
>
> I have no idea how much of this made it into working systems,
>
You can get the same effect of a mobile IP with IPv4 using a VPN, such
as OpenVPN.
I think I've come to the conclusion that this is the only way to
reliably have a mobile NFS mount. The server really has too much
investment in the IP of the client, both for locking and for the reply
cache. Because of these, the Linux NFS client tries hard to reconnect
from the same source address when it does reconnect, and this is
unlikely to change (I suspect).
When a client does change IP address, all NFS mounts should be
unmounted (probably umount --lazy) and an automounter should be used
to re-establish them on demand.
It is conceivable that the connection could be broken and
re-established without requiring the re-mount. But as it would have
to drop all locks and lose any benefits of the server's reply cache,
it should not happen automatically.
If you want really mobile mounts, use OpenVPN or similar.
Thanks everyone for your input.
NeilBrown