* Inconsistent error codes between NFSv4 and v3 on network issues
@ 2013-03-01 11:43 Jan Engelhardt
2013-03-04 14:16 ` J. Bruce Fields
2013-03-04 17:47 ` Chuck Lever
0 siblings, 2 replies; 8+ messages in thread
From: Jan Engelhardt @ 2013-03-01 11:43 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: linux-nfs
Hi.
I had here a case with a Linux 3.7.9 system, a virtual machine in a
RFC1918 range, that did not want to mount NFS.
linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
Process 1477 attached
[pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
mount.nfs: mount system call failed
[pid 1477] +++ exited with 32 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1477, si_status=32, si_utime=0, si_stime=0} ---
+++ exited with 32 +++
Nothing in dmesg...
[ 84.202243] RPC: Registered named UNIX socket transport module.
[ 84.202246] RPC: Registered udp transport module.
[ 84.202248] RPC: Registered tcp transport module.
[ 84.202249] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 84.205909] FS-Cache: Loaded
[ 84.208782] FS-Cache: Netfs 'nfs' registered for caching
[ 84.215733] NFS: Registering the id_resolver key type
[ 84.215762] Key type id_resolver registered
[ 84.215763] Key type id_legacy registered
When mounting with NFSv3, the error became clear:
# strace -fe mount -s 65536 mount -t nfs 134.76.12.5:/X /mnt -o nfsvers=3,nolock
Process 1550 attached
mount.nfs: Network is unreachable
[pid 1550] +++ exited with 32 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1550, si_status=32, si_utime=0, si_stime=0} ---
+++ exited with 32 +++
Can NFSv4 be made to return -ENETUNREACH as well?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-01 11:43 Inconsistent error codes between NFSv4 and v3 on network issues Jan Engelhardt
@ 2013-03-04 14:16 ` J. Bruce Fields
2013-03-04 14:16 ` J. Bruce Fields
2013-03-04 17:47 ` Chuck Lever
1 sibling, 1 reply; 8+ messages in thread
From: J. Bruce Fields @ 2013-03-04 14:16 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-nfs
Adding Chuck to cc:, as he's probably done the most mucking with the
mount code in recent years?
--b.
On Fri, Mar 01, 2013 at 12:43:58PM +0100, Jan Engelhardt wrote:
> Hi.
>
>
> I had here a case with a Linux 3.7.9 system, a virtual machine in a
> RFC1918 range, that did not want to mount NFS.
>
> linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
> Process 1477 attached
> [pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
> mount.nfs: mount system call failed
> [pid 1477] +++ exited with 32 +++
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1477, si_status=32, si_utime=0, si_stime=0} ---
> +++ exited with 32 +++
>
> Nothing in dmesg...
>
> [ 84.202243] RPC: Registered named UNIX socket transport module.
> [ 84.202246] RPC: Registered udp transport module.
> [ 84.202248] RPC: Registered tcp transport module.
> [ 84.202249] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 84.205909] FS-Cache: Loaded
> [ 84.208782] FS-Cache: Netfs 'nfs' registered for caching
> [ 84.215733] NFS: Registering the id_resolver key type
> [ 84.215762] Key type id_resolver registered
> [ 84.215763] Key type id_legacy registered
>
> When mounting with NFSv3, the error became clear:
>
> # strace -fe mount -s 65536 mount -t nfs 134.76.12.5:/X /mnt -o nfsvers=3,nolock
> Process 1550 attached
> mount.nfs: Network is unreachable
> [pid 1550] +++ exited with 32 +++
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1550, si_status=32, si_utime=0, si_stime=0} ---
> +++ exited with 32 +++
>
> Can NFSv4 be made to return -ENETUNREACH as well?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-04 14:16 ` J. Bruce Fields
@ 2013-03-04 14:16 ` J. Bruce Fields
0 siblings, 0 replies; 8+ messages in thread
From: J. Bruce Fields @ 2013-03-04 14:16 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linux-nfs, chuck.lever
Um, for real this time.
On Mon, Mar 04, 2013 at 09:16:00AM -0500, J. Bruce Fields wrote:
> Adding Chuck to cc:, as he's probably done the most mucking with the
> mount code in recent years?
>
> --b.
>
> On Fri, Mar 01, 2013 at 12:43:58PM +0100, Jan Engelhardt wrote:
> > Hi.
> >
> >
> > I had here a case with a Linux 3.7.9 system, a virtual machine in a
> > RFC1918 range, that did not want to mount NFS.
> >
> > linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
> > Process 1477 attached
> > [pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
> > mount.nfs: mount system call failed
> > [pid 1477] +++ exited with 32 +++
> > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1477, si_status=32, si_utime=0, si_stime=0} ---
> > +++ exited with 32 +++
> >
> > Nothing in dmesg...
> >
> > [ 84.202243] RPC: Registered named UNIX socket transport module.
> > [ 84.202246] RPC: Registered udp transport module.
> > [ 84.202248] RPC: Registered tcp transport module.
> > [ 84.202249] RPC: Registered tcp NFSv4.1 backchannel transport module.
> > [ 84.205909] FS-Cache: Loaded
> > [ 84.208782] FS-Cache: Netfs 'nfs' registered for caching
> > [ 84.215733] NFS: Registering the id_resolver key type
> > [ 84.215762] Key type id_resolver registered
> > [ 84.215763] Key type id_legacy registered
> >
> > When mounting with NFSv3, the error became clear:
> >
> > # strace -fe mount -s 65536 mount -t nfs 134.76.12.5:/X /mnt -o nfsvers=3,nolock
> > Process 1550 attached
> > mount.nfs: Network is unreachable
> > [pid 1550] +++ exited with 32 +++
> > --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1550, si_status=32, si_utime=0, si_stime=0} ---
> > +++ exited with 32 +++
> >
> > Can NFSv4 be made to return -ENETUNREACH as well?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-01 11:43 Inconsistent error codes between NFSv4 and v3 on network issues Jan Engelhardt
2013-03-04 14:16 ` J. Bruce Fields
@ 2013-03-04 17:47 ` Chuck Lever
2013-03-04 19:10 ` Jan Engelhardt
1 sibling, 1 reply; 8+ messages in thread
From: Chuck Lever @ 2013-03-04 17:47 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: J. Bruce Fields, linux-nfs
On Mar 1, 2013, at 6:43 AM, Jan Engelhardt <jengelh@inai.de> wrote:
> Hi.
>
>
> I had here a case with a Linux 3.7.9 system, a virtual machine in a
> RFC1918 range, that did not want to mount NFS.
>
> linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
> Process 1477 attached
> [pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
"clientaddr=0.0.0.0" is interesting: perhaps the mount.nfs command should have failed right there.
But, let's find out why the kernel is returning EIO. Enter:
# rpcdebug -m nfs -s all
# rpcdebug -m rpc -s call xprt
Try your NFSv4 mount command again, then post relevant excerpts from the kernel log.
By the way, does this happen on older kernels?
> mount.nfs: mount system call failed
> [pid 1477] +++ exited with 32 +++
> --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1477, si_status=32, si_utime=0, si_stime=0} ---
> +++ exited with 32 +++
>
> Nothing in dmesg...
>
> [ 84.202243] RPC: Registered named UNIX socket transport module.
> [ 84.202246] RPC: Registered udp transport module.
> [ 84.202248] RPC: Registered tcp transport module.
> [ 84.202249] RPC: Registered tcp NFSv4.1 backchannel transport module.
> [ 84.205909] FS-Cache: Loaded
> [ 84.208782] FS-Cache: Netfs 'nfs' registered for caching
> [ 84.215733] NFS: Registering the id_resolver key type
> [ 84.215762] Key type id_resolver registered
> [ 84.215763] Key type id_legacy registered
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-04 17:47 ` Chuck Lever
@ 2013-03-04 19:10 ` Jan Engelhardt
2013-03-04 20:43 ` Myklebust, Trond
0 siblings, 1 reply; 8+ messages in thread
From: Jan Engelhardt @ 2013-03-04 19:10 UTC (permalink / raw)
To: Chuck Lever; +Cc: J. Bruce Fields, linux-nfs
On Monday 2013-03-04 18:47, Chuck Lever wrote:
>>
>> linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
>> Process 1477 attached
>> [pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
>
>"clientaddr=0.0.0.0" is interesting: perhaps the mount.nfs command
>should have failed right there.
Maybe (since there is no route). Maybe not: I would interpret 0.0.0.0
as "kernel will pick something".
This kernel 3.7.9 system has rpcbind-0.2.0_git201103171419-7.1.1.x86_64
and nfs-client-1.2.7-2.1.1.x86_64.
>But, let's find out why the kernel is returning EIO. Enter:
>
> # rpcdebug -m nfs -s all
> # rpcdebug -m rpc -s call xprt
>
>Try your NFSv4 mount command again, then post relevant excerpts from the kernel log.
[205196.949572] NFS: nfs mount opts='vers=4,addr=134.76.12.5,clientaddr=0.0.0.0'
[205196.949580] NFS: parsing nfs mount option 'vers=4'
[205196.949586] NFS: parsing nfs mount option 'addr=134.76.12.5'
[205196.949592] NFS: parsing nfs mount option 'clientaddr=0.0.0.0'
[205196.949597] NFS: MNTPATH: '/X'
[205196.949600] --> nfs4_try_mount()
[205196.949607] --> nfs4_create_server()
[205196.949639] --> nfs4_init_server()
[205196.949641] --> nfs4_set_client()
[205196.949644] --> nfs_get_client(134.76.12.5,v4)
[205196.949651] NFS: get client cookie (0xffff88007abe3800/0xffff88007ba29420)
[205196.949666] RPC: created transport ffff88007ba50800 with 65536 slots
[205196.949670] RPC: creating nfs client for 134.76.12.5 (xprt ffff88007ba50800)
[205196.949693] RPC: 2 call_start nfs4 proc NULL (sync)
[205196.949705] RPC: 2 call_reserve (status 0)
[205196.949709] RPC: 2 reserved req ffff88007b342800 xid 11fca56c
[205196.949712] RPC: 2 call_reserveresult (status 0)
[205196.949714] RPC: 2 call_refresh (status 0)
[205196.949716] RPC: 2 call_refreshresult (status 0)
[205196.949718] RPC: 2 call_allocate (status 0)
[205196.949722] RPC: 2 call_bind (status 0)
[205196.949724] RPC: 2 call_connect xprt ffff88007ba50800 is not connected
[205196.949727] RPC: 2 xprt_connect xprt ffff88007ba50800 is not connected
[205196.949765] RPC: 2 xprt_connect_status: error 101 connecting to server 134.76.12.5
[205196.949779] RPC: 2 call_connect_status (status -5)
[205196.949791] RPC: 2 release request ffff88007b342800
[205196.949794] RPC: rpc_release_client(ffff88007b342e00)
[205196.949797] RPC: shutting down nfs client for 134.76.12.5
[205196.949798] RPC: rpc_release_client(ffff88007b342e00)
[205196.949801] RPC: destroying nfs client for 134.76.12.5
[205196.949803] RPC: destroying transport ffff88007ba50800
[205196.949812] RPC: disconnected transport ffff88007ba50800
[205196.949816] nfs_create_rpc_client: cannot create RPC client. Error = -5
[205196.949818] --> nfs_put_client({1})
[205196.949820] --> nfs_free_client(4)
[205196.949822] NFS: releasing client cookie (0xffff88007abe3800/0xffff88007ba29420)
[205196.949824] <-- nfs_free_client()
[205196.949826] <-- nfs4_init_client() = xerror -5
[205196.949828] <-- nfs4_set_client() = xerror -5
[205196.949829] <-- nfs4_init_server() = -5
[205196.949831] --> nfs_free_server()
[205196.949850] <-- nfs_free_server()
[205196.949852] <-- nfs4_create_server() = error -5
[205196.949856] <-- nfs4_try_mount() = -5 [error]
Just nuke your default route, and it should be easily reproducible.
>By the way, does this happen on older kernels?
On kernel 3.0.51 with rpcbind-0.1.6+git20080930-6.18.1 and
nfs-utils-1.2.3, I observe that
rtsnode1:~ # strace -fe mount -s 65535 mount -t nfs 134.76.12.5:/X /mnt -o
nfsvers=4
Process 24358 attached
Process 24357 suspended
[pid 24358] mount("134.76.12.5:/X", "/mnt", "nfs", 0,
"nfsvers=4,addr=134.76.12.5,clientaddr=0.0.0.0"
<hang, but interruptible>
rpcdebug/dmesg:
[790206.304549] NFS: nfs mount opts='nfsvers=4,addr=134.76.12.5,clientaddr=0.0.0.0'
[790206.304549] NFS: parsing nfs mount option 'nfsvers=4'
[790206.304549] NFS: parsing nfs mount option 'addr=134.76.12.5'
[790206.304549] NFS: parsing nfs mount option 'clientaddr=0.0.0.0'
[790206.304549] NFS: MNTPATH: '/X'
[790206.304549] --> nfs4_try_mount()
[790206.304549] --> nfs4_create_server()
[790206.304549] --> nfs4_init_server()
[790206.304549] --> nfs4_set_client()
[790206.304549] --> nfs_get_client(134.76.12.5,v4)
[790206.304549] NFS: get client cookie (0xffff880079a16400/0xffff880079cd41e0)
[790206.304549] RPC: created transport ffff880078f26800 with 16 slots
[790206.304549] RPC: creating nfs client for 134.76.12.5 (xprt ffff880078f26800)
[790206.304550] RPC: 45 call_start nfs4 proc NULL (sync)
[790206.304550] RPC: 45 call_reserve (status 0)
[790206.304550] RPC: 45 reserved req ffff880037a16000 xid 68604dfd
[790206.304550] RPC: 45 call_reserveresult (status 0)
[790206.304550] RPC: 45 call_refresh (status 0)
[790206.304550] RPC: 45 call_refreshresult (status 0)
[790206.304550] RPC: 45 call_allocate (status 0)
[790206.304550] RPC: 45 call_bind (status 0)
[790206.304550] RPC: 45 call_connect xprt ffff880078f26800 is not connected
[790206.304550] RPC: 45 xprt_connect xprt ffff880078f26800 is not connected
<no further output until Ctrl-C issued>
[790320.020951] RPC: 45 xprt_connect_status: error 512 connecting to server 134.76.12.5
[790320.020960] RPC: 45 release request ffff880037a16000
[790320.020963] RPC: rpc_release_client(ffff880079bc0200)
[790320.020968] RPC: shutting down nfs client for 134.76.12.5
[790320.020970] RPC: rpc_release_client(ffff880079bc0200)
[790320.020973] RPC: destroying nfs client for 134.76.12.5
[790320.024752] RPC: destroying transport ffff880078f26800
[790320.024767] RPC: disconnected transport ffff880078f26800
[790320.024772] nfs_create_rpc_client: cannot create RPC client. Error = -5
[790320.024775] <-- nfs4_init_client() = xerror -5
[790320.024777] --> nfs_put_client({1})
[790320.024781] --> nfs_free_client(4)
[790320.024783] NFS: releasing client cookie (0xffff880079a16400/0xffff880079cd41e0)
[790320.024788] <-- nfs_free_client()
[790320.024789] <-- nfs4_set_client() = xerror -5
[790320.024791] <-- nfs4_init_server() = -5
[790320.024810] --> nfs_free_server()
[790320.024816] <-- nfs_free_server()
[790320.024818] <-- nfs4_create_server() = error -5
[790320.024822] <-- nfs4_try_mount() = -5 [error]
And, if network connectivity is present, this occurs:
# strace -fe mount -s 65535 mount -t nfs 134.76.12.5:/X /mnt -o nfsvers=4
Process 24383 attached
Process 24382 suspended
[pid 24383] mount("134.76.12.5:/X", "/mnt", "nfs", 0,
"nfsvers=4,addr=134.76.12.5,clientaddr=10.10.7.142" <short wait> ) = 0
Process 24382 resumed
Process 24383 detached
--- SIGCHLD (Child exited) @ 0 (0) ---
And that then probably answers your clientaddr= concern.
So what 3.7.x does better is that it immediately identifies
EHOSTUNREACH/ENETUNREACH while 3.0.x waits for Godot.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-04 19:10 ` Jan Engelhardt
@ 2013-03-04 20:43 ` Myklebust, Trond
2013-03-04 22:37 ` Myklebust, Trond
0 siblings, 1 reply; 8+ messages in thread
From: Myklebust, Trond @ 2013-03-04 20:43 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Chuck Lever, J. Bruce Fields, linux-nfs
On Mon, 2013-03-04 at 20:10 +0100, Jan Engelhardt wrote:
> On Monday 2013-03-04 18:47, Chuck Lever wrote:
> >>
> >> linux-3lzm:~ # strace -fe mount mount -t nfs 134.76.12.5:/X /mnt
> >> Process 1477 attached
> >> [pid 1515] mount("134.76.12.5:/X", "/mnt", "nfs", 0, "vers=4,addr=134.76.12.5,clientaddr=0.0.0.0") = -1 EIO (Input/output error)
> >
> >"clientaddr=0.0.0.0" is interesting: perhaps the mount.nfs command
> >should have failed right there.
>
> Maybe (since there is no route). Maybe not: I would interpret 0.0.0.0
> as "kernel will pick something".
>
> This kernel 3.7.9 system has rpcbind-0.2.0_git201103171419-7.1.1.x86_64
> and nfs-client-1.2.7-2.1.1.x86_64.
>
>
> >But, let's find out why the kernel is returning EIO. Enter:
> >
> > # rpcdebug -m nfs -s all
> > # rpcdebug -m rpc -s call xprt
> >
> >Try your NFSv4 mount command again, then post relevant excerpts from the kernel log.
>
> [205196.949572] NFS: nfs mount opts='vers=4,addr=134.76.12.5,clientaddr=0.0.0.0'
> [205196.949580] NFS: parsing nfs mount option 'vers=4'
> [205196.949586] NFS: parsing nfs mount option 'addr=134.76.12.5'
> [205196.949592] NFS: parsing nfs mount option 'clientaddr=0.0.0.0'
> [205196.949597] NFS: MNTPATH: '/X'
> [205196.949600] --> nfs4_try_mount()
> [205196.949607] --> nfs4_create_server()
> [205196.949639] --> nfs4_init_server()
> [205196.949641] --> nfs4_set_client()
> [205196.949644] --> nfs_get_client(134.76.12.5,v4)
> [205196.949651] NFS: get client cookie (0xffff88007abe3800/0xffff88007ba29420)
> [205196.949666] RPC: created transport ffff88007ba50800 with 65536 slots
> [205196.949670] RPC: creating nfs client for 134.76.12.5 (xprt ffff88007ba50800)
> [205196.949693] RPC: 2 call_start nfs4 proc NULL (sync)
> [205196.949705] RPC: 2 call_reserve (status 0)
> [205196.949709] RPC: 2 reserved req ffff88007b342800 xid 11fca56c
> [205196.949712] RPC: 2 call_reserveresult (status 0)
> [205196.949714] RPC: 2 call_refresh (status 0)
> [205196.949716] RPC: 2 call_refreshresult (status 0)
> [205196.949718] RPC: 2 call_allocate (status 0)
> [205196.949722] RPC: 2 call_bind (status 0)
> [205196.949724] RPC: 2 call_connect xprt ffff88007ba50800 is not connected
> [205196.949727] RPC: 2 xprt_connect xprt ffff88007ba50800 is not connected
> [205196.949765] RPC: 2 xprt_connect_status: error 101 connecting to server 134.76.12.5
> [205196.949779] RPC: 2 call_connect_status (status -5)
> [205196.949791] RPC: 2 release request ffff88007b342800
> [205196.949794] RPC: rpc_release_client(ffff88007b342e00)
> [205196.949797] RPC: shutting down nfs client for 134.76.12.5
> [205196.949798] RPC: rpc_release_client(ffff88007b342e00)
> [205196.949801] RPC: destroying nfs client for 134.76.12.5
> [205196.949803] RPC: destroying transport ffff88007ba50800
> [205196.949812] RPC: disconnected transport ffff88007ba50800
> [205196.949816] nfs_create_rpc_client: cannot create RPC client. Error = -5
> [205196.949818] --> nfs_put_client({1})
> [205196.949820] --> nfs_free_client(4)
> [205196.949822] NFS: releasing client cookie (0xffff88007abe3800/0xffff88007ba29420)
> [205196.949824] <-- nfs_free_client()
> [205196.949826] <-- nfs4_init_client() = xerror -5
> [205196.949828] <-- nfs4_set_client() = xerror -5
> [205196.949829] <-- nfs4_init_server() = -5
> [205196.949831] --> nfs_free_server()
> [205196.949850] <-- nfs_free_server()
> [205196.949852] <-- nfs4_create_server() = error -5
> [205196.949856] <-- nfs4_try_mount() = -5 [error]
>
> Just nuke your default route, and it should be easily reproducible.
>
The problem is that call_connect_status() is converting that ENETUNREACH
into a EIO. We shouldn't be doing that, but should leave it up to the
caller (i.e. the NFS layer) to perform that kind of mapping.
Cheers
Trond
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-04 20:43 ` Myklebust, Trond
@ 2013-03-04 22:37 ` Myklebust, Trond
2013-03-13 14:47 ` Jan Engelhardt
0 siblings, 1 reply; 8+ messages in thread
From: Myklebust, Trond @ 2013-03-04 22:37 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Chuck Lever, J. Bruce Fields, linux-nfs
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
On Mon, 2013-03-04 at 20:43 +0000, Myklebust, Trond wrote:
> On Mon, 2013-03-04 at 20:10 +0100, Jan Engelhardt wrote:
> > Just nuke your default route, and it should be easily reproducible.
> >
>
> The problem is that call_connect_status() is converting that ENETUNREACH
> into a EIO. We shouldn't be doing that, but should leave it up to the
> caller (i.e. the NFS layer) to perform that kind of mapping.
Could you please check if the attached patch helps.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-SUNRPC-Report-network-connection-errors-correctly-fo.patch --]
[-- Type: text/x-patch; name="0001-SUNRPC-Report-network-connection-errors-correctly-fo.patch", Size: 2560 bytes --]
From 724bf7a71b44145811a1fec3b20a26bd1edae51b Mon Sep 17 00:00:00 2001
From: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Mon, 4 Mar 2013 17:29:33 -0500
Subject: [PATCH] SUNRPC: Report network/connection errors correctly for
SOFTCONN rpc tasks
In the case of a SOFTCONN rpc task, we really want to ensure that it
reports errors like ENETUNREACH back to the caller. Currently, only
some of these errors are being reported back (connect errors are not),
and they are being converted by the RPC layer into EIO.
Reported-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
---
net/sunrpc/clnt.c | 24 ++++++++++++++----------
net/sunrpc/xprtsock.c | 8 ++++----
2 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index dcc446e..b95a0a2 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -1644,22 +1644,26 @@ call_connect_status(struct rpc_task *task)
dprint_status(task);
- task->tk_status = 0;
- if (status >= 0 || status == -EAGAIN) {
- clnt->cl_stats->netreconn++;
- task->tk_action = call_transmit;
- return;
- }
-
trace_rpc_connect_status(task, status);
switch (status) {
/* if soft mounted, test if we've timed out */
case -ETIMEDOUT:
task->tk_action = call_timeout;
- break;
- default:
- rpc_exit(task, -EIO);
+ return;
+ case -ECONNREFUSED:
+ case -ECONNRESET:
+ case -ENETUNREACH:
+ if (RPC_IS_SOFTCONN(task))
+ break;
+ /* retry with existing socket, after a delay */
+ case 0:
+ case -EAGAIN:
+ task->tk_status = 0;
+ clnt->cl_stats->netreconn++;
+ task->tk_action = call_transmit;
+ return;
}
+ rpc_exit(task, status);
}
/*
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index c1d8476..3081620 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -2202,10 +2202,6 @@ static void xs_tcp_setup_socket(struct work_struct *work)
*/
xs_tcp_force_close(xprt);
break;
- case -ECONNREFUSED:
- case -ECONNRESET:
- case -ENETUNREACH:
- /* retry with existing socket, after a delay */
case 0:
case -EINPROGRESS:
case -EALREADY:
@@ -2216,6 +2212,10 @@ static void xs_tcp_setup_socket(struct work_struct *work)
/* Happens, for instance, if the user specified a link
* local IPv6 address without a scope-id.
*/
+ case -ECONNREFUSED:
+ case -ECONNRESET:
+ case -ENETUNREACH:
+ /* retry with existing socket, after a delay */
goto out;
}
out_eagain:
--
1.8.1.4
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: Inconsistent error codes between NFSv4 and v3 on network issues
2013-03-04 22:37 ` Myklebust, Trond
@ 2013-03-13 14:47 ` Jan Engelhardt
0 siblings, 0 replies; 8+ messages in thread
From: Jan Engelhardt @ 2013-03-13 14:47 UTC (permalink / raw)
To: Myklebust, Trond; +Cc: Chuck Lever, J. Bruce Fields, linux-nfs
On Monday 2013-03-04 23:37, Myklebust, Trond wrote:
>On Mon, 2013-03-04 at 20:43 +0000, Myklebust, Trond wrote:
>> On Mon, 2013-03-04 at 20:10 +0100, Jan Engelhardt wrote:
>> > Just nuke your default route, and it should be easily reproducible.
>> >
>>
>> The problem is that call_connect_status() is converting that ENETUNREACH
>> into a EIO. We shouldn't be doing that, but should leave it up to the
>> caller (i.e. the NFS layer) to perform that kind of mapping.
>
>Could you please check if the attached patch helps.
With the patch, I still get EIO from the mount syscall.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-03-13 14:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-01 11:43 Inconsistent error codes between NFSv4 and v3 on network issues Jan Engelhardt
2013-03-04 14:16 ` J. Bruce Fields
2013-03-04 14:16 ` J. Bruce Fields
2013-03-04 17:47 ` Chuck Lever
2013-03-04 19:10 ` Jan Engelhardt
2013-03-04 20:43 ` Myklebust, Trond
2013-03-04 22:37 ` Myklebust, Trond
2013-03-13 14:47 ` Jan Engelhardt
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.