NFS hangs in spite of intr option when connection is lost
in [General Linux]
|
Prev: html to video?
Next: Cloning a Windows system?
From: Rahul on 29 Jul 2010 21:21 I have a read only, hard, NFS mount to a remote machines NFS exported dir. But sometimes the remote machine is down. In such a scenario if a ls is attempted on the NFS dir from the client then the session hangs. I thought the intr option was a way to fix this. But it still doesn't work. i.e. Ctrl+C doesn't get me back to the command prompt. I'm using bash. Any other workarounds? Or maybe I am mis-interpreting the use of the intr option. cat /etc/fstab [snip] remote.foo.edu:/exported_dir /mnt/remote nfs ro,hard,intr 0 0 [I was simulating a loss of connection by merely starting iptables on remotemachine and blocking the client] -- Rahul
From: Grant on 30 Jul 2010 01:22 On Fri, 30 Jul 2010 01:21:14 +0000 (UTC), Rahul <nospam(a)nospam.invalid> wrote: >I have a read only, hard, NFS mount to a remote machines NFS exported dir. >But sometimes the remote machine is down. In such a scenario if a ls is >attempted on the NFS dir from the client then the session hangs. > >I thought the intr option was a way to fix this. But it still doesn't work. >i.e. Ctrl+C doesn't get me back to the command prompt. I'm using bash. > >Any other workarounds? Or maybe I am mis-interpreting the use of the intr >option. > >cat /etc/fstab >[snip] >remote.foo.edu:/exported_dir /mnt/remote nfs >ro,hard,intr 0 0 > >[I was simulating a loss of connection by merely starting iptables on >remotemachine and blocking the client] Which process is blocking? Is it different if you pull the plug? Grant.
From: Rahul on 30 Jul 2010 02:33 Grant <omg(a)grrr.id.au> wrote in news:tao456p2v59ck9q1s43p0isabdaame5so0@ 4ax.com: > Which process is blocking? I'm not sure what exactly this means? I was under the impression my NFS client is waiting infinitely for the non-responsive NFS-server? Or not? > Is it different if you pull the plug? > The machine was a bit too far away to pull the plug. But I tried to do the closest. i.e. I rebooted the NFS exporting machine. The client NFS still hangs the same as before. This time it didn't even recover when the NFS-server came back online after its reboot. I had to actually kill my shell session where I was running an ls on the NFS dir. My speculation is that the new NFS server comes up using a different set of ports so the hung client can't find it. But the basic problem still remains: Why is the intr option not obeyed? -- Rahul
From: Rahul on 30 Jul 2010 04:16 The Natural Philosopher <tnp(a)invalid.invalid> wrote in news:i2tu0d$tua$1(a)news.albasani.net: > Rahul wrote: >> Grant <omg(a)grrr.id.au> wrote in >> news:tao456p2v59ck9q1s43p0isabdaame5so0@ 4ax.com: > > Anyway, you can check if you are using TCP rather than UDP as its a > mount option. If you have hard mounted the NFS filesystem it oughter > be in /etc/fstab. I think it is using UDP. That's the default option. cat /etc/fstab [snip] eu001:/tmp /mnt/tmp/ nfs ro,hard,intr 0 0 > > Look first find out whether you are using UDP or TCP transports. TCP UDP. But just for the heck of it I tried to switch to TCP by using: eu001:/tmp /mnt/tmp/ nfs ro,hard,intr,tcp 0 0 But the situation remains the same. The client still hangs. Therefore I doubt UDP vs TCP is making a difference here. One thing that confuses me: Is the choice between UDP vs TCP solely in the hands of the NFS client and the server will use either? Another confusing aspect is that rpcinfo returns a mix of UDP and TCP ports open. [root(a)euadmin ~]# rpcinfo -p eu001 program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 695 status 100024 1 tcp 698 status 100021 1 udp 60240 nlockmgr 100021 3 udp 60240 nlockmgr 100021 4 udp 60240 nlockmgr 100021 1 tcp 54277 nlockmgr 100021 3 tcp 54277 nlockmgr 100021 4 tcp 54277 nlockmgr 100011 1 udp 650 rquotad 100011 2 udp 650 rquotad 100011 1 tcp 653 rquotad 100011 2 tcp 653 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 663 mountd 100005 1 tcp 666 mountd 100005 2 udp 663 mountd 100005 2 tcp 666 mountd 100005 3 udp 663 mountd 100005 3 tcp 666 mountd -- Rahul
From: The Natural Philosopher on 30 Jul 2010 04:25
Rahul wrote: > The Natural Philosopher <tnp(a)invalid.invalid> wrote in > news:i2tu0d$tua$1(a)news.albasani.net: > >> Rahul wrote: >>> Grant <omg(a)grrr.id.au> wrote in >>> news:tao456p2v59ck9q1s43p0isabdaame5so0@ 4ax.com: >> Anyway, you can check if you are using TCP rather than UDP as its a >> mount option. If you have hard mounted the NFS filesystem it oughter >> be in /etc/fstab. > > I think it is using UDP. That's the default option. > > cat /etc/fstab > [snip] > eu001:/tmp /mnt/tmp/ nfs ro,hard,intr > 0 0 >> Look first find out whether you are using UDP or TCP transports. TCP > > UDP. > > But just for the heck of it I tried to switch to TCP by using: > > eu001:/tmp /mnt/tmp/ nfs > ro,hard,intr,tcp 0 0 > well that ought to work as far as my limited and rusty understanding goes. You could try dumping the hard bit, as the actress said to the bishop.. > But the situation remains the same. The client still hangs. Therefore I > doubt UDP vs TCP is making a difference here. > > One thing that confuses me: Is the choice between UDP vs TCP solely in > the hands of the NFS client and the server will use either? > > > Another confusing aspect is that rpcinfo returns a mix of UDP and TCP > ports open. > The server will offer both. The client may decide which to use. |