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 04:25 PM, Andreas Hofmeister wrote: > On 23.07.2011 21:54, Digimer wrote: >> >> Thanks for the reply Andy. >> >> The hardware (Intel Pro1000/CT NICs[1] and a D-Link DGS-3100-24[2]) >> 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: >> > >> > --- 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 >> ==== > > Ah. The '-Mdo' argument to ping just spares you the 'tcpdump'. > >> 1. >> http://www.intel.com/products/desktop/adapters/gigabit-ct/gigabit-ct-overview.htm >> 2. http://dlink.ca/products/?pid=DGS-3100-24 > > Mhh, I have a peer of nodes - actually with DRBD 0.8.11, not 0.8.10 as I > thought - and Intel 82571EB NICs working rather well, but then these are > connected back-to-back. > > We had some bad experience with a D-Link switch in the past. Don't > remember the model, but we eventually scraped it because of the troubles. > > If you use pacemaker+corosync, you may want to check the "netmtu" > setting in "corosync.conf". That should not affect DRBD though. > > Ciao > Andi I used RHCS2 (openais)+rgmanager on EL5.7 in this case. However, only DRBD uses the eth1 interfaces. I've had 9kb JF working on these interfaces and using this switch before using CentOS 5.6 + DRBD 8.3.9, for what that is worth. Also, only cman was running when I tried to manually bring up the DRBD resources. Even then, the only reason I started cman first was so that the 'obliterate-peer.sh' fence handler would work in the case that DRBD tried to call it. Is it possible for me to enable debugging mode on DRBD (or increasing log output)? I'm really quite curious to sort out what is wrong. :) -- 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?"