* clients cannot reconnect to mounted nfs shares after server restart
[not found] <AANLkTinD01zA=DTXEDG5pXVYcrEGsWOyXcMta0rzvB6n@mail.gmail.com>
@ 2011-02-01 3:24 ` camden lindsay
2011-02-01 18:15 ` J. Bruce Fields
0 siblings, 1 reply; 4+ messages in thread
From: camden lindsay @ 2011-02-01 3:24 UTC (permalink / raw)
To: linux-nfs
Having an issue i believe is an NFS bug, but would like someone to
verify as well as... point me the correct direction to submit a bug as
needed if it indeed is.
Situation:
NFS server running
Client connected with mounted share
NFS server is shut down -- (halt or /etc/init.d/nfs stop)
NFS server is turned on (booted or /etc/init.d/nfs start)
Outcome:
NFS client that was connected does not reconnect to that share automatically
NFS client that was connected cannot reconnect via umount then mount again
No other nfs client can connect to that share, before or after origial
NFS clients attempts to connect/reconnect
NFS clients CAN connect to a different share.
Details/logs:
Server shows that client is authenticating:
Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from
192.168.11.49:674 for /mnt/store/public (/mnt/store/public)
Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from
192.168.11.49:763 for /mnt/store/public (/mnt/store/public)
Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from
192.168.11.49:932 for /mnt/store/public (/mnt/store/public)
Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from
192.168.11.49:942 for /mnt/store/public (/mnt/store/public)
Client shows retransmission:
dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/
mount.nfs: timeout set for Mon Jan 31 19:09:32 2011
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
Server Version:
net-fs/nfs-utils
Latest version available: 1.1.4-r1
Latest version installed: 1.1.4-r1
Size of files: 574 kB
Homepage: http://linux-nfs.org/
Description: NFS client and server daemons
License: GPL-2
(server is on Gentoo, client on Ubuntu)
Thanks!
Camden
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart
2011-02-01 3:24 ` clients cannot reconnect to mounted nfs shares after server restart camden lindsay
@ 2011-02-01 18:15 ` J. Bruce Fields
2011-02-04 9:31 ` camden lindsay
0 siblings, 1 reply; 4+ messages in thread
From: J. Bruce Fields @ 2011-02-01 18:15 UTC (permalink / raw)
To: camden lindsay; +Cc: linux-nfs
On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote:
> Having an issue i believe is an NFS bug, but would like someone to
> verify as well as... point me the correct direction to submit a bug as
> needed if it indeed is.
> Situation:
> NFS server running
> Client connected with mounted share
> NFS server is shut down -- (halt or /etc/init.d/nfs stop)
> NFS server is turned on (booted or /etc/init.d/nfs start)
>
> Outcome:
> NFS client that was connected does not reconnect to that share automatically
> NFS client that was connected cannot reconnect via umount then mount again
> No other nfs client can connect to that share, before or after origial
How long have you waited?
> NFS clients attempts to connect/reconnect
> NFS clients CAN connect to a different share.
> Details/logs:
> Server shows that client is authenticating:
> Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from
> 192.168.11.49:674 for /mnt/store/public (/mnt/store/public)
> Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from
> 192.168.11.49:763 for /mnt/store/public (/mnt/store/public)
> Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from
> 192.168.11.49:932 for /mnt/store/public (/mnt/store/public)
> Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from
> 192.168.11.49:942 for /mnt/store/public (/mnt/store/public)
A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem,
then ^C tcpdump, then send us tmp.pcap) might help.
>
> Client shows retransmission:
> dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/
> mount.nfs: timeout set for Mon Jan 31 19:09:32 2011
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
>
> Server Version:
> net-fs/nfs-utils
> Latest version available: 1.1.4-r1
> Latest version installed: 1.1.4-r1
> Size of files: 574 kB
> Homepage: http://linux-nfs.org/
> Description: NFS client and server daemons
> License: GPL-2
> (server is on Gentoo, client on Ubuntu)
Note most of the NFS code is actually in the kernel, so the kernel
version(s) involved would be useful too.
--b.
> Thanks!
> Camden
> --
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart
2011-02-01 18:15 ` J. Bruce Fields
@ 2011-02-04 9:31 ` camden lindsay
2011-02-06 20:47 ` J. Bruce Fields
0 siblings, 1 reply; 4+ messages in thread
From: camden lindsay @ 2011-02-04 9:31 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
Thanks for the response:
I have waited quite some time-- many minutes-- and still cannot reconnect.
Server --> BigBox dylan # uname -a
Linux BigBox 2.6.36-gentoo-r5 #5 SMP Tue Feb 1 06:57:03 PST 2011
x86_64 Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
What i have found is that, with a newer client, i get slightly more
information at the command line, pointing to stale nfs filehandle:
Client1:
Linux shobuntu 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010
i686 GNU/Linux
mount.nfs: timeout set for Fri Feb 4 01:19:37 2011
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: text-based options: 'addr=192.168.11.10'
Client2:
Linux core2buntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43
UTC 2011 x86_64 GNU/Linux
mount.nfs: timeout set for Fri Feb 4 01:18:17 2011
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: mount(2): Stale NFS file handle
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: mount(2): Stale NFS file handle
mount.nfs: text-based options: 'addr=192.168.11.10'
mount.nfs: mount(2): Stale NFS file handle
Should this automatically converge at some point?
If so, how long should i expect for convergence?
Thanks!
Camden
On Tue, Feb 1, 2011 at 10:15 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote:
> > Having an issue i believe is an NFS bug, but would like someone to
> > verify as well as... point me the correct direction to submit a bug as
> > needed if it indeed is.
> > Situation:
> > NFS server running
> > Client connected with mounted share
> > NFS server is shut down -- (halt or /etc/init.d/nfs stop)
> > NFS server is turned on (booted or /etc/init.d/nfs start)
> >
> > Outcome:
> > NFS client that was connected does not reconnect to that share automatically
> > NFS client that was connected cannot reconnect via umount then mount again
> > No other nfs client can connect to that share, before or after origial
>
> How long have you waited?
>
> > NFS clients attempts to connect/reconnect
> > NFS clients CAN connect to a different share.
> > Details/logs:
> > Server shows that client is authenticating:
> > Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from
> > 192.168.11.49:674 for /mnt/store/public (/mnt/store/public)
> > Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from
> > 192.168.11.49:763 for /mnt/store/public (/mnt/store/public)
> > Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from
> > 192.168.11.49:932 for /mnt/store/public (/mnt/store/public)
> > Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from
> > 192.168.11.49:942 for /mnt/store/public (/mnt/store/public)
>
> A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem,
> then ^C tcpdump, then send us tmp.pcap) might help.
>
> >
> > Client shows retransmission:
> > dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/
> > mount.nfs: timeout set for Mon Jan 31 19:09:32 2011
> > mount.nfs: text-based options: 'addr=192.168.11.10'
> > mount.nfs: text-based options: 'addr=192.168.11.10'
> > mount.nfs: text-based options: 'addr=192.168.11.10'
> > mount.nfs: text-based options: 'addr=192.168.11.10'
> > mount.nfs: text-based options: 'addr=192.168.11.10'
> >
> > Server Version:
> > net-fs/nfs-utils
> > Latest version available: 1.1.4-r1
> > Latest version installed: 1.1.4-r1
> > Size of files: 574 kB
> > Homepage: http://linux-nfs.org/
> > Description: NFS client and server daemons
> > License: GPL-2
> > (server is on Gentoo, client on Ubuntu)
>
> Note most of the NFS code is actually in the kernel, so the kernel
> version(s) involved would be useful too.
>
> --b.
>
> > Thanks!
> > Camden
> > --
> > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart
2011-02-04 9:31 ` camden lindsay
@ 2011-02-06 20:47 ` J. Bruce Fields
0 siblings, 0 replies; 4+ messages in thread
From: J. Bruce Fields @ 2011-02-06 20:47 UTC (permalink / raw)
To: camden lindsay; +Cc: linux-nfs
On Fri, Feb 04, 2011 at 01:31:05AM -0800, camden lindsay wrote:
> Thanks for the response:
> I have waited quite some time-- many minutes-- and still cannot reconnect.
The wait shouldn't be more than a minute or two after the nfs server is
back up and running. And mount should pretty much never see a stale
filehandle error.
A network trace showing the stale errors after reboot, together with the
output of
cat /proc/net/rpc/nfsd.*/content
blkid
on the server, could be useful.
--b.
>
> Server --> BigBox dylan # uname -a
> Linux BigBox 2.6.36-gentoo-r5 #5 SMP Tue Feb 1 06:57:03 PST 2011
> x86_64 Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux
>
> What i have found is that, with a newer client, i get slightly more
> information at the command line, pointing to stale nfs filehandle:
> Client1:
> Linux shobuntu 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010
> i686 GNU/Linux
> mount.nfs: timeout set for Fri Feb 4 01:19:37 2011
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: text-based options: 'addr=192.168.11.10'
>
> Client2:
> Linux core2buntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43
> UTC 2011 x86_64 GNU/Linux
> mount.nfs: timeout set for Fri Feb 4 01:18:17 2011
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: mount(2): Stale NFS file handle
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: mount(2): Stale NFS file handle
> mount.nfs: text-based options: 'addr=192.168.11.10'
> mount.nfs: mount(2): Stale NFS file handle
>
>
> Should this automatically converge at some point?
> If so, how long should i expect for convergence?
>
> Thanks!
> Camden
>
> On Tue, Feb 1, 2011 at 10:15 AM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote:
> > > Having an issue i believe is an NFS bug, but would like someone to
> > > verify as well as... point me the correct direction to submit a bug as
> > > needed if it indeed is.
> > > Situation:
> > > NFS server running
> > > Client connected with mounted share
> > > NFS server is shut down -- (halt or /etc/init.d/nfs stop)
> > > NFS server is turned on (booted or /etc/init.d/nfs start)
> > >
> > > Outcome:
> > > NFS client that was connected does not reconnect to that share automatically
> > > NFS client that was connected cannot reconnect via umount then mount again
> > > No other nfs client can connect to that share, before or after origial
> >
> > How long have you waited?
> >
> > > NFS clients attempts to connect/reconnect
> > > NFS clients CAN connect to a different share.
> > > Details/logs:
> > > Server shows that client is authenticating:
> > > Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from
> > > 192.168.11.49:674 for /mnt/store/public (/mnt/store/public)
> > > Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from
> > > 192.168.11.49:763 for /mnt/store/public (/mnt/store/public)
> > > Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from
> > > 192.168.11.49:932 for /mnt/store/public (/mnt/store/public)
> > > Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from
> > > 192.168.11.49:942 for /mnt/store/public (/mnt/store/public)
> >
> > A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem,
> > then ^C tcpdump, then send us tmp.pcap) might help.
> >
> > >
> > > Client shows retransmission:
> > > dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/
> > > mount.nfs: timeout set for Mon Jan 31 19:09:32 2011
> > > mount.nfs: text-based options: 'addr=192.168.11.10'
> > > mount.nfs: text-based options: 'addr=192.168.11.10'
> > > mount.nfs: text-based options: 'addr=192.168.11.10'
> > > mount.nfs: text-based options: 'addr=192.168.11.10'
> > > mount.nfs: text-based options: 'addr=192.168.11.10'
> > >
> > > Server Version:
> > > net-fs/nfs-utils
> > > Latest version available: 1.1.4-r1
> > > Latest version installed: 1.1.4-r1
> > > Size of files: 574 kB
> > > Homepage: http://linux-nfs.org/
> > > Description: NFS client and server daemons
> > > License: GPL-2
> > > (server is on Gentoo, client on Ubuntu)
> >
> > Note most of the NFS code is actually in the kernel, so the kernel
> > version(s) involved would be useful too.
> >
> > --b.
> >
> > > Thanks!
> > > Camden
> > > --
> > > 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-06 20:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTinD01zA=DTXEDG5pXVYcrEGsWOyXcMta0rzvB6n@mail.gmail.com>
2011-02-01 3:24 ` clients cannot reconnect to mounted nfs shares after server restart camden lindsay
2011-02-01 18:15 ` J. Bruce Fields
2011-02-04 9:31 ` camden lindsay
2011-02-06 20:47 ` J. Bruce Fields
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).