Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 07/23/2011 03:30 PM, Andreas Hofmeister wrote: > On 23.07.2011 06:30, Digimer wrote: >> Any way to debug this? If it looks like a DRBD bug, > > I don't think so. I have DRBD running with jumbo frames on several > machines and it just work (albeit with 0.8.10). > > Check you networking. > > Try "ping -c1 -Mdo -s 8192 <other node>", that should tell you if you > get jumbo frames to the other side or if there is a problem on the IP > layer. > > If you get something like "From <other node> icmp_seq=1 Frag needed and > DF set (mtu = <actual MTU>)", check your devices MTU and check your > routing as it is actually possible to define a MTU per route. > > If you just get no answer or the response is too short, check the specs > of your network hardware. The supported size for jumbo frames varies > widely, not just between vendors but also between NIC chips from the > same vendor. In some cases, even different chips support by the same > driver differ in the maximum frame size. > > Ciao > Andi Thanks for the reply Andy. The hardware (Intel Pro1000/CT NICs and a D-Link DGS-3100-24) both support 9kb+ frames (and JFs are enabled in the switch). With the MTU on either node's DRBD interface (eth1) set to 9000, I confirmed that JFs worked using a method very similar to what you suggested: node1: ==== [root at an-node06 ~]# ifconfig eth1 mtu 9000 [root at an-node06 ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:1B:21:72:9B:59 inet addr:192.168.2.76 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe72:9b59/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:12614 errors:0 dropped:0 overruns:0 frame:0 TX packets:14197 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:15357943 (14.6 MiB) TX bytes:15483995 (14.7 MiB) Interrupt:17 Memory:feae0000-feb00000 [root at an-node06 ~]# ping -s 8900 -c 1 an-node07.sn PING an-node07.sn (192.168.2.77) 8900(8928) bytes of data. 8908 bytes from an-node07.sn (192.168.2.77): icmp_seq=1 ttl=64 time=0.686 ms --- an-node07.sn ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.686/0.686/0.686/0.000 ms ==== node2: ==== [root at an-node07 ~]# ifconfig eth1 mtu 9000 [root at an-node07 ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:1B:21:72:96:F2 inet addr:192.168.2.77 Bcast:192.168.2.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe72:96f2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:30593 errors:0 dropped:0 overruns:0 frame:0 TX packets:26756 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:31161397 (29.7 MiB) TX bytes:30838239 (29.4 MiB) Interrupt:17 Memory:feae0000-feb00000 [root at an-node07 ~]# clear; tcpdump -i eth1 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 15:45:10.474134 IP an-node06.sn > an-node07.sn: ICMP echo request, id 11554, seq 1, length 8908 15:45:10.475236 IP an-node07.sn > an-node06.sn: ICMP echo reply, id 11554, seq 1, length 8908 ==== Just one packet used. So I know that the interfaces are properly using 9000 byte frames. This is why I thought the problem was within DRBD itself. 1. http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm 2. http://dlink.ca/products/?pid=DGS-3100-24 -- Digimer E-Mail: digimer at alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "At what point did we forget that the Space Shuttle was, essentially, a program that strapped human beings to an explosion and tried to stab through the sky with fire and math?"