* NFS v4 client blocks when using UDP protocol @ 2011-11-10 8:11 fanchaoting 2011-11-10 14:50 ` Myklebust, Trond 0 siblings, 1 reply; 9+ messages in thread From: fanchaoting @ 2011-11-10 8:11 UTC (permalink / raw) To: linux-nfs, Trond.Myklebust hi, 1. When I use nfs i find "NFS v4 client blocks when using UDP protocol". 2. when i use RHEL6.1GA i didn't find this problem , but when i use RHEL6.2Beta i find this problem. 3. Can you tell me which patch causes this problem ? thank you !!! ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: NFS v4 client blocks when using UDP protocol 2011-11-10 8:11 NFS v4 client blocks when using UDP protocol fanchaoting @ 2011-11-10 14:50 ` Myklebust, Trond 0 siblings, 0 replies; 9+ messages in thread From: Myklebust, Trond @ 2011-11-10 14:50 UTC (permalink / raw) To: fanchaoting, linux-nfs > -----Original Message----- > From: fanchaoting [mailto:fanchaoting@cn.fujitsu.com] > Sent: Thursday, November 10, 2011 3:11 AM > To: linux-nfs@vger.kernel.org; Myklebust, Trond > Subject: NFS v4 client blocks when using UDP protocol > > hi, > 1. When I use nfs i find "NFS v4 client blocks when using UDP > protocol". UDP is not a supported protocol for NFSv4. It is explicitly banned in the NFS spec (RFC3530). > 2. when i use RHEL6.1GA i didn't find this problem , but when i use > RHEL6.2Beta i find this problem. > 3. Can you tell me which patch causes this problem ? None of them. UDP is not a supported configuration. Trond ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <EB0F26AF-C0DB-4861-ABB5-72E39CB38090@bull.net>]
* NFS v4 client blocks when using UDP protocol [not found] <EB0F26AF-C0DB-4861-ABB5-72E39CB38090@bull.net> @ 2011-03-29 14:32 ` Menyhart Zoltan 2011-03-29 15:06 ` Chuck Lever 0 siblings, 1 reply; 9+ messages in thread From: Menyhart Zoltan @ 2011-03-29 14:32 UTC (permalink / raw) To: linux-nfs Hi, NFS v4 client blocks under heavy load, when using UDP protocol. No progress can be seen, the test program "iozone" cannot be killed. "nfsiostat 10 -p" reports 2 "nfs_writepages()" calls on every 10 seconds: server:/ mounted on /mnt/test: op/s rpc bklog 0.00 0.00 read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) 0.000 0.000 0.000 0 (0.0%) 0.000 0.000 write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) 0.000 0.000 0.000 0 (0.0%) 0.000 0.000 0 nfs_readpage() calls read 0 pages 0 nfs_readpages() calls read 0 pages 0 nfs_updatepage() calls 0 nfs_writepage() calls wrote 0 pages 2 nfs_writepages() calls wrote 0 pages (0.0 pages per call) Checking the test program with the "crash" reports: PID: 6185 TASK: ffff8804047020c0 CPU: 0 COMMAND: "iozone" #0 [ffff88036ce638b8] schedule at ffffffff814d9459 #1 [ffff88036ce63980] schedule_timeout at ffffffff814da152 #2 [ffff88036ce63a30] io_schedule_timeout at ffffffff814d8f2f #3 [ffff88036ce63a60] balance_dirty_pages at ffffffff811213d1 #4 [ffff88036ce63b80] balance_dirty_pages_ratelimited_nr at ffffffff811217e4 #5 [ffff88036ce63b90] generic_file_buffered_write at ffffffff8110d993 #6 [ffff88036ce63c60] __generic_file_aio_write at ffffffff8110f230 #7 [ffff88036ce63d20] generic_file_aio_write at ffffffff8110f4cf #8 [ffff88036ce63d70] nfs_file_write at ffffffffa05e4c2e #9 [ffff88036ce63dc0] do_sync_write at ffffffff81170bda #10 [ffff88036ce63ef0] vfs_write at ffffffff81170ed8 #11 [ffff88036ce63f30] sys_write at ffffffff81171911 #12 [ffff88036ce63f80] system_call_fastpath at ffffffff8100b172 RIP: 0000003709a0e490 RSP: 00007fffba8eac78 RFLAGS: 00000246 RAX: 0000000000000001 RBX: ffffffff8100b172 RCX: 0000003709a0ec10 RDX: 0000000000400000 RSI: 00007fe469600000 RDI: 0000000000000003 RBP: 0000000000000298 R8: 0000000000000000 R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe469600000 R13: 0000000000eb4c20 R14: 0000000000400000 R15: 0000000000eb4c20 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b No activity can be seen with wireshark on the network. Rebooting the client and restarting the test can show another failing point: PID: 4723 TASK: ffff8803fc235580 CPU: 2 COMMAND: "iozone" #0 [ffff880417e2dc08] schedule at ffffffff814d9459 #1 [ffff880417e2dcd0] io_schedule at ffffffff814d9c43 #2 [ffff880417e2dcf0] sync_page at ffffffff8110d01d #3 [ffff880417e2dd00] __wait_on_bit at ffffffff814da4af #4 [ffff880417e2dd50] wait_on_page_bit at ffffffff8110d1d3 #5 [ffff880417e2ddb0] wait_on_page_writeback_range at ffffffff8110d5eb #6 [ffff880417e2deb0] filemap_write_and_wait_range at ffffffff8110d7b8 #7 [ffff880417e2dee0] vfs_fsync_range at ffffffff8119f11e #8 [ffff880417e2df30] vfs_fsync at ffffffff8119f1ed #9 [ffff880417e2df40] do_fsync at ffffffff8119f22e #10 [ffff880417e2df70] sys_fsync at ffffffff8119f280 #11 [ffff880417e2df80] system_call_fastpath at ffffffff8100b172 RIP: 0000003709a0ebb0 RSP: 00007fff5517dc28 RFLAGS: 00000212 RAX: 000000000000004a RBX: ffffffff8100b172 RCX: 00000000000000ef RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000008000 R8: 00000000ffffffff R9: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffff8119f280 R13: ffff880417e2df78 R14: 00000000011d7c30 R15: 0000000000000000 ORIG_RAX: 000000000000004a CS: 0033 SS: 002b Sometimes console messages appear, like: INFO: task iozone:4723 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. iozone D 0000000000000002 0 4723 4683 0x00000080 ffff880417e2dcc8 0000000000000086 ffff880417e2dc48 ffffffffa042fc99 ffff88036e53d440 ffff8803e386aac0 ffff880402cf4610 ffff88036e53d448 ffff8803fc235b38 ffff880417e2dfd8 000000000000f558 ffff8803fc235b38 Call Trace: [<ffffffffa042fc99>] ? rpc_run_task+0xd9/0x130 [sunrpc] [<ffffffff81098aa9>] ? ktime_get_ts+0xa9/0xe0 [<ffffffff8110cfe0>] ? sync_page+0x0/0x50 [<ffffffff814d9c43>] io_schedule+0x73/0xc0 [<ffffffff8110d01d>] sync_page+0x3d/0x50 [<ffffffff814da4af>] __wait_on_bit+0x5f/0x90 [<ffffffff8110d1d3>] wait_on_page_bit+0x73/0x80 [<ffffffff8108df40>] ? wake_bit_function+0x0/0x50 [<ffffffff81122f25>] ? pagevec_lookup_tag+0x25/0x40 [<ffffffff8110d5eb>] wait_on_page_writeback_range+0xfb/0x190 [<ffffffff8110d7b8>] filemap_write_and_wait_range+0x78/0x90 [<ffffffff8119f11e>] vfs_fsync_range+0x7e/0xe0 [<ffffffff8119f1ed>] vfs_fsync+0x1d/0x20 [<ffffffff8119f22e>] do_fsync+0x3e/0x60 [<ffffffff8119f280>] sys_fsync+0x10/0x20 [<ffffffff8100b172>] system_call_fastpath+0x16/0x1b This problem can be systematically reproduced with the following test: iozone -a -c -e -E -L 64 -m -S 4096 -f /mnt/test/file -g 20G -n 1M -y 4K It can be reproduced with both type of networks we have, see below. Switching on RPC debugging with "sysctl -w sunrpc.rpc_debug=65535" gives: -pid- flgs status -client- --rqstp- -timeout ---ops-- 28139 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog 29167 0001 -11 ffff88040f403400 ffff8803ff405130 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend 29172 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog ... 51364 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog 55355 0001 -11 ffff88040f403400 ffff8803ff405450 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend 55356 0001 -11 ffff88040f403400 ffff8803ff404000 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend 55357 0001 -11 ffff88040f403400 ffff8803ff404c80 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend 55369 0001 -11 ffff88040f403400 ffff8803ff4055e0 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend ... 55370 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog 55371 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog ... No error messages in "dmesg" neither in "/var/log/messages" at the server side. Our test HW: 2 * Supermicro R460, 2 dual core Xeons 5150 2.66GHz in each machine InfiniBand Mellanox Technologies MT26418 in DDR mode, IP over IB Intel Corporation 80003ES2LAN Gigabit Ethernet Controller, point to point direct connection SW: Kernels up to 2.6.38-rc8 Server side: A SW RAID "/dev/md0" mounted on "/md0" is exported: /dev/md0: Version : 0.90 Creation Time : Wed Feb 18 17:18:34 2009 Raid Level : raid0 Array Size : 357423360 (340.87 GiB 366.00 GB) Raid Devices : 5 Total Devices : 5 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Wed Feb 18 17:18:34 2009 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Chunk Size : 256K UUID : 05fae940:c7540b1e:d0f324d8:8f753e72 Events : 0.1 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 2 8 48 2 active sync /dev/sdd 3 8 64 3 active sync /dev/sde 4 8 80 4 active sync /dev/sdf /etc/exports: /md0 *(rw,insecure,no_subtree_check,sync,fsid=0) The client machine mounts it as follows: mount -o async,udp 192.168.1.79:/ /mnt/test # Ethernet or mount -o async,udp 192.168.42.79:/ /mnt/test # IP over IB Have you already seen this problem? Thank you in advance, Zoltan Menyhart ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NFS v4 client blocks when using UDP protocol 2011-03-29 14:32 ` Menyhart Zoltan @ 2011-03-29 15:06 ` Chuck Lever 2011-03-29 15:26 ` Menyhart Zoltan 0 siblings, 1 reply; 9+ messages in thread From: Chuck Lever @ 2011-03-29 15:06 UTC (permalink / raw) To: Menyhart Zoltan; +Cc: linux-nfs Zoltan- As far as I know, NFSv4 is not supported on UDP transports. Some of it may work, but no warrantee, either expressed or implied, is given. :-) On Mar 29, 2011, at 10:32 AM, Menyhart Zoltan wrote: > Hi, > > NFS v4 client blocks under heavy load, when using UDP protocol. > No progress can be seen, the test program "iozone" cannot be killed. > > "nfsiostat 10 -p" reports 2 "nfs_writepages()" calls on every 10 seconds: > > server:/ mounted on /mnt/test: > op/s rpc bklog > 0.00 0.00 > read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) > 0.000 0.000 0.000 0 (0.0%) 0.000 0.000 > write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) > 0.000 0.000 0.000 0 (0.0%) 0.000 0.000 > 0 nfs_readpage() calls read 0 pages > 0 nfs_readpages() calls read 0 pages > 0 nfs_updatepage() calls > 0 nfs_writepage() calls wrote 0 pages > 2 nfs_writepages() calls wrote 0 pages (0.0 pages per call) > > Checking the test program with the "crash" reports: > > PID: 6185 TASK: ffff8804047020c0 CPU: 0 COMMAND: "iozone" > #0 [ffff88036ce638b8] schedule at ffffffff814d9459 > #1 [ffff88036ce63980] schedule_timeout at ffffffff814da152 > #2 [ffff88036ce63a30] io_schedule_timeout at ffffffff814d8f2f > #3 [ffff88036ce63a60] balance_dirty_pages at ffffffff811213d1 > #4 [ffff88036ce63b80] balance_dirty_pages_ratelimited_nr at ffffffff811217e4 > #5 [ffff88036ce63b90] generic_file_buffered_write at ffffffff8110d993 > #6 [ffff88036ce63c60] __generic_file_aio_write at ffffffff8110f230 > #7 [ffff88036ce63d20] generic_file_aio_write at ffffffff8110f4cf > #8 [ffff88036ce63d70] nfs_file_write at ffffffffa05e4c2e > #9 [ffff88036ce63dc0] do_sync_write at ffffffff81170bda > #10 [ffff88036ce63ef0] vfs_write at ffffffff81170ed8 > #11 [ffff88036ce63f30] sys_write at ffffffff81171911 > #12 [ffff88036ce63f80] system_call_fastpath at ffffffff8100b172 > RIP: 0000003709a0e490 RSP: 00007fffba8eac78 RFLAGS: 00000246 > RAX: 0000000000000001 RBX: ffffffff8100b172 RCX: 0000003709a0ec10 > RDX: 0000000000400000 RSI: 00007fe469600000 RDI: 0000000000000003 > RBP: 0000000000000298 R8: 0000000000000000 R9: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe469600000 > R13: 0000000000eb4c20 R14: 0000000000400000 R15: 0000000000eb4c20 > ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b > > No activity can be seen with wireshark on the network. > Rebooting the client and restarting the test can show another failing point: > > PID: 4723 TASK: ffff8803fc235580 CPU: 2 COMMAND: "iozone" > #0 [ffff880417e2dc08] schedule at ffffffff814d9459 > #1 [ffff880417e2dcd0] io_schedule at ffffffff814d9c43 > #2 [ffff880417e2dcf0] sync_page at ffffffff8110d01d > #3 [ffff880417e2dd00] __wait_on_bit at ffffffff814da4af > #4 [ffff880417e2dd50] wait_on_page_bit at ffffffff8110d1d3 > #5 [ffff880417e2ddb0] wait_on_page_writeback_range at ffffffff8110d5eb > #6 [ffff880417e2deb0] filemap_write_and_wait_range at ffffffff8110d7b8 > #7 [ffff880417e2dee0] vfs_fsync_range at ffffffff8119f11e > #8 [ffff880417e2df30] vfs_fsync at ffffffff8119f1ed > #9 [ffff880417e2df40] do_fsync at ffffffff8119f22e > #10 [ffff880417e2df70] sys_fsync at ffffffff8119f280 > #11 [ffff880417e2df80] system_call_fastpath at ffffffff8100b172 > RIP: 0000003709a0ebb0 RSP: 00007fff5517dc28 RFLAGS: 00000212 > RAX: 000000000000004a RBX: ffffffff8100b172 RCX: 00000000000000ef > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 > RBP: 0000000000008000 R8: 00000000ffffffff R9: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000246 R12: ffffffff8119f280 > R13: ffff880417e2df78 R14: 00000000011d7c30 R15: 0000000000000000 > ORIG_RAX: 000000000000004a CS: 0033 SS: 002b > > Sometimes console messages appear, like: > > INFO: task iozone:4723 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > iozone D 0000000000000002 0 4723 4683 0x00000080 > ffff880417e2dcc8 0000000000000086 ffff880417e2dc48 ffffffffa042fc99 > ffff88036e53d440 ffff8803e386aac0 ffff880402cf4610 ffff88036e53d448 > ffff8803fc235b38 ffff880417e2dfd8 000000000000f558 ffff8803fc235b38 > Call Trace: > [<ffffffffa042fc99>] ? rpc_run_task+0xd9/0x130 [sunrpc] > [<ffffffff81098aa9>] ? ktime_get_ts+0xa9/0xe0 > [<ffffffff8110cfe0>] ? sync_page+0x0/0x50 > [<ffffffff814d9c43>] io_schedule+0x73/0xc0 > [<ffffffff8110d01d>] sync_page+0x3d/0x50 > [<ffffffff814da4af>] __wait_on_bit+0x5f/0x90 > [<ffffffff8110d1d3>] wait_on_page_bit+0x73/0x80 > [<ffffffff8108df40>] ? wake_bit_function+0x0/0x50 > [<ffffffff81122f25>] ? pagevec_lookup_tag+0x25/0x40 > [<ffffffff8110d5eb>] wait_on_page_writeback_range+0xfb/0x190 > [<ffffffff8110d7b8>] filemap_write_and_wait_range+0x78/0x90 > [<ffffffff8119f11e>] vfs_fsync_range+0x7e/0xe0 > [<ffffffff8119f1ed>] vfs_fsync+0x1d/0x20 > [<ffffffff8119f22e>] do_fsync+0x3e/0x60 > [<ffffffff8119f280>] sys_fsync+0x10/0x20 > [<ffffffff8100b172>] system_call_fastpath+0x16/0x1b > > This problem can be systematically reproduced with the following test: > > iozone -a -c -e -E -L 64 -m -S 4096 -f /mnt/test/file -g 20G -n 1M -y 4K > > It can be reproduced with both type of networks we have, see below. > > Switching on RPC debugging with "sysctl -w sunrpc.rpc_debug=65535" gives: > > -pid- flgs status -client- --rqstp- -timeout ---ops-- > 28139 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog > 29167 0001 -11 ffff88040f403400 ffff8803ff405130 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend > 29172 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog > ... > 51364 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog > 55355 0001 -11 ffff88040f403400 ffff8803ff405450 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend > 55356 0001 -11 ffff88040f403400 ffff8803ff404000 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend > 55357 0001 -11 ffff88040f403400 ffff8803ff404c80 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend > 55369 0001 -11 ffff88040f403400 ffff8803ff4055e0 0 ffffffffa06157e0 nfsv4 WRITE a:call_status q:xprt_resend > ... > 55370 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog > 55371 0001 -11 ffff88040f403400 (null) 0 ffffffffa06157e0 nfsv4 WRITE a:call_reserveresult q:xprt_backlog > ... > > No error messages in "dmesg" neither in "/var/log/messages" at the server side. > > > Our test HW: > 2 * Supermicro R460, 2 dual core Xeons 5150 2.66GHz in each machine > InfiniBand Mellanox Technologies MT26418 in DDR mode, IP over IB > Intel Corporation 80003ES2LAN Gigabit Ethernet Controller, point to point direct connection > > SW: > Kernels up to 2.6.38-rc8 > > > Server side: > > A SW RAID "/dev/md0" mounted on "/md0" is exported: > > /dev/md0: > Version : 0.90 > Creation Time : Wed Feb 18 17:18:34 2009 > Raid Level : raid0 > Array Size : 357423360 (340.87 GiB 366.00 GB) > Raid Devices : 5 > Total Devices : 5 > Preferred Minor : 0 > Persistence : Superblock is persistent > Update Time : Wed Feb 18 17:18:34 2009 > State : clean > Active Devices : 5 > Working Devices : 5 > Failed Devices : 0 > Spare Devices : 0 > Chunk Size : 256K > UUID : 05fae940:c7540b1e:d0f324d8:8f753e72 > Events : 0.1 > > Number Major Minor RaidDevice State > 0 8 16 0 active sync /dev/sdb > 1 8 32 1 active sync /dev/sdc > 2 8 48 2 active sync /dev/sdd > 3 8 64 3 active sync /dev/sde > 4 8 80 4 active sync /dev/sdf > > /etc/exports: > /md0 *(rw,insecure,no_subtree_check,sync,fsid=0) > > The client machine mounts it as follows: > > mount -o async,udp 192.168.1.79:/ /mnt/test # Ethernet > or > mount -o async,udp 192.168.42.79:/ /mnt/test # IP over IB > > > Have you already seen this problem? > Thank you in advance, > > Zoltan Menyhart > > -- > 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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NFS v4 client blocks when using UDP protocol 2011-03-29 15:06 ` Chuck Lever @ 2011-03-29 15:26 ` Menyhart Zoltan 2011-03-29 15:46 ` Chuck Lever 2011-03-29 15:50 ` peter.staubach 0 siblings, 2 replies; 9+ messages in thread From: Menyhart Zoltan @ 2011-03-29 15:26 UTC (permalink / raw) To: Chuck Lever; +Cc: linux-nfs Chuck Lever wrote: > Zoltan- > > As far as I know, NFSv4 is not supported on UDP transports. >Some of it may work, but no warrantee, either expressed or implied, is given. :-) Do you mean the Linux implementation? Because the RFC 3530 speaks about how to do NFS v4 over UDP and UDP6. Thank you, Zoltan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NFS v4 client blocks when using UDP protocol 2011-03-29 15:26 ` Menyhart Zoltan @ 2011-03-29 15:46 ` Chuck Lever 2011-03-29 15:50 ` peter.staubach 1 sibling, 0 replies; 9+ messages in thread From: Chuck Lever @ 2011-03-29 15:46 UTC (permalink / raw) To: Menyhart Zoltan; +Cc: linux-nfs On Mar 29, 2011, at 11:26 AM, Menyhart Zoltan wrote: > Chuck Lever wrote: >> Zoltan- >> >> As far as I know, NFSv4 is not supported on UDP transports. >> Some of it may work, but no warrantee, either expressed or implied, is given. :-) > > Do you mean the Linux implementation? > Because the RFC 3530 speaks about how to do NFS v4 over UDP and UDP6. My reading of 3530 is that NFSv4 is not allowed over non-stream transports like UDP. The Linux implementation does not support NFSv4 over UDP, even though it allows you to try it. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: NFS v4 client blocks when using UDP protocol 2011-03-29 15:26 ` Menyhart Zoltan 2011-03-29 15:46 ` Chuck Lever @ 2011-03-29 15:50 ` peter.staubach 2011-03-30 0:12 ` Tom Haynes 1 sibling, 1 reply; 9+ messages in thread From: peter.staubach @ 2011-03-29 15:50 UTC (permalink / raw) To: Zoltan.Menyhart, chuck.lever; +Cc: linux-nfs It does talk about NFS over UDP, interestingly, but the text on page 25, indicates that the transport of choice MUST be one of the IETF-approved congestion control transport protocols, of which, UDP is not one. Perhaps some clean up of RFC3530bis and RFC5661 could include removal of the UDP mentions. ps -----Original Message----- From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Menyhart Zoltan Sent: Tuesday, March 29, 2011 11:26 AM To: Chuck Lever Cc: linux-nfs@vger.kernel.org Subject: Re: NFS v4 client blocks when using UDP protocol Chuck Lever wrote: > Zoltan- > > As far as I know, NFSv4 is not supported on UDP transports. >Some of it may work, but no warrantee, either expressed or implied, is given. :-) Do you mean the Linux implementation? Because the RFC 3530 speaks about how to do NFS v4 over UDP and UDP6. Thank you, Zoltan -- 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] 9+ messages in thread
* Re: NFS v4 client blocks when using UDP protocol 2011-03-29 15:50 ` peter.staubach @ 2011-03-30 0:12 ` Tom Haynes 2011-03-30 9:00 ` Trond Myklebust 0 siblings, 1 reply; 9+ messages in thread From: Tom Haynes @ 2011-03-30 0:12 UTC (permalink / raw) To: peter.staubach; +Cc: Zoltan.Menyhart, chuck.lever, linux-nfs On Tue, Mar 29, 2011 at 11:50:36AM -0400, peter.staubach@emc.com wrote: > It does talk about NFS over UDP, interestingly, but the text on page 25, indicates that the transport of choice MUST be one of the IETF-approved congestion control transport protocols, of which, UDP is not one. > > Perhaps some clean up of RFC3530bis and RFC5661 could include removal of the UDP mentions. The text in 3530bis could be made to match that in 5661: It is permissible for a connectionless transport to be used under NFSv4.1; however, reliable and in-order delivery of data combined with congestion control by the connectionless transport is REQUIRED. As a consequence, UDP by itself MUST NOT be used as an NFSv4.1 transport. NFSv4.1 assumes that a client transport address and server transport address used to send data over a transport together constitute a connection, even if the underlying transport eschews the concept of a connection. But as we can see 5661 is very strong. > > ps > > > -----Original Message----- > From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Menyhart Zoltan > Sent: Tuesday, March 29, 2011 11:26 AM > To: Chuck Lever > Cc: linux-nfs@vger.kernel.org > Subject: Re: NFS v4 client blocks when using UDP protocol > > Chuck Lever wrote: > > Zoltan- > > > > As far as I know, NFSv4 is not supported on UDP transports. > >Some of it may work, but no warrantee, either expressed or implied, is given. :-) > > Do you mean the Linux implementation? > Because the RFC 3530 speaks about how to do NFS v4 over UDP and UDP6. > > Thank you, > > Zoltan > > -- > 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 > > -- > 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 -- Tom Haynes ex-cfb ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NFS v4 client blocks when using UDP protocol 2011-03-30 0:12 ` Tom Haynes @ 2011-03-30 9:00 ` Trond Myklebust 0 siblings, 0 replies; 9+ messages in thread From: Trond Myklebust @ 2011-03-30 9:00 UTC (permalink / raw) To: Tom Haynes; +Cc: peter.staubach, Zoltan.Menyhart, chuck.lever, linux-nfs On Tue, 2011-03-29 at 19:12 -0500, Tom Haynes wrote: > On Tue, Mar 29, 2011 at 11:50:36AM -0400, peter.staubach@emc.com wrote: > > It does talk about NFS over UDP, interestingly, but the text on page 25, indicates that the transport of choice MUST be one of the IETF-approved congestion control transport protocols, of which, UDP is not one. > > > > Perhaps some clean up of RFC3530bis and RFC5661 could include removal of the UDP mentions. > > The text in 3530bis could be made to match that in 5661: > > It is permissible for a connectionless transport to be used under > NFSv4.1; however, reliable and in-order delivery of data combined > with congestion control by the connectionless transport is REQUIRED. > As a consequence, UDP by itself MUST NOT be used as an NFSv4.1 > transport. NFSv4.1 assumes that a client transport address and > server transport address used to send data over a transport together > constitute a connection, even if the underlying transport eschews the > concept of a connection. > > But as we can see 5661 is very strong. I think Peter is referring to the text in section 2.2 and section 17.2 which describes the format for netids and universal addresses specifically for the UDP case. I agree with Peter's suggestion that we should just delete that text. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-11-10 14:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-10 8:11 NFS v4 client blocks when using UDP protocol fanchaoting
2011-11-10 14:50 ` Myklebust, Trond
[not found] <EB0F26AF-C0DB-4861-ABB5-72E39CB38090@bull.net>
2011-03-29 14:32 ` Menyhart Zoltan
2011-03-29 15:06 ` Chuck Lever
2011-03-29 15:26 ` Menyhart Zoltan
2011-03-29 15:46 ` Chuck Lever
2011-03-29 15:50 ` peter.staubach
2011-03-30 0:12 ` Tom Haynes
2011-03-30 9:00 ` Trond Myklebust
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).