NFS and mobile clients - can it work?

NFS and mobile clients - can it work?

[Neil Brown]

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

Re: NFS and mobile clients - can it work?

[Krishna Kumar2]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: NFS and mobile clients - can it work?

[Suresh Jayaraman]

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

Re: NFS and mobile clients - can it work?

[Ric Wheeler]

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,
>
>   

Re: NFS and mobile clients - can it work?

[Neil Brown]

On Wednesday September 24, rwheeler@redhat.com 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

Re: NFS and mobile clients - can it work?

[Steve Dickson]

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.

Re: NFS and mobile clients - can it work?

[Jim Rees]

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.