From: Suresh Jayaraman <sjayaraman@suse.de>
To: Neil Brown <neilb@suse.de>
Cc: linux-nfs@vger.kernel.org
Subject: Re: NFS and mobile clients - can it work?
Date: Wed, 24 Sep 2008 12:49:02 +0530 [thread overview]
Message-ID: <48D9E9E6.8000706@suse.de> (raw)
In-Reply-To: <18646.58594.377630.950531-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
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
next prev parent reply other threads:[~2008-09-24 7:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-22 0:20 NFS and mobile clients - can it work? Neil Brown
[not found] ` <18646.58594.377630.950531-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-09-22 5:30 ` Krishna Kumar2
2008-09-24 7:19 ` Suresh Jayaraman [this message]
2008-09-24 13:26 ` Ric Wheeler
2008-09-25 4:13 ` Neil Brown
2008-09-24 15:24 ` Steve Dickson
[not found] ` <48DA5B93.5030307-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2008-09-24 15:52 ` Jim Rees
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48D9E9E6.8000706@suse.de \
--to=sjayaraman@suse.de \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.