My thanks to Jayson and especially Wendy for providing so much help
with this issue.  With a little help from Coraid, I've troubleshot the
performance issues down to one of the two ports on the Coraid device. 
In the end, I was able to move the performance problem from on of my
two hosts to the other just by swapping ports.  I'll follow up with
Coraid to see if I have a hardware problem.
<br><br>It's really nice to have such a great level of community
support.  Wendy, I'd be happy to share the particulars on my deployment
once I get things stabilized.<br><br>Thanks again!<br>Tom<br><br><div><span class="gmail_quote">On 12/11/06, <b class="gmail_sendername">Wendy Cheng</b> <<a href="mailto:wcheng@redhat.com">wcheng@redhat.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Jayson Vantuyl wrote:<br>> Tom,<br>><br>> I currently administer a system running a similar but larger setup, so
<br>> I may be able to help you.<br>><br>> First, make sure you contact Coraid.  They are really good about<br>> helping with this stuff.<br>Yes, this is another big area that needs to get looked into. Network
<br>block device is so new (at least on Linux) that it requires some<br>fine-tuning. If folks have working experiences and willing to share, we<br>would be very happy to learn from them.<br><br>-- Wendy<br>><br>> Second, have you looked at /dev/etherd/err?  There is usually a lot of
<br>> good debugging there.<br>><br>> Third, have you upgraded the firmware in the Coraid and built the<br>> newest AoE driver?  These are absolutely critical in getting the best<br>> performance / reliability and generally the plain kernel driver has
<br>> fallen behind.  They assure me they're working on this and I can vouch<br>> for the fact that this driver is essentially the one in the kernel<br>> with development necessary to make it work--not some sort of vendor
<br>> supplied out-of-tree driver.<br>><br>> Finally, make sure you have good switches.  I have had a number of<br>> switches that drop a packet here and there.  These are death to AoE<br>> performance.  Gigabit is generally a must as well.
<br>><br>> On Dec 10, 2006, at 2:03 AM, <a href="mailto:bigendian+gfs@gmail.com">bigendian+gfs@gmail.com</a><br>> <mailto:<a href="mailto:bigendian+gfs@gmail.com">bigendian+gfs@gmail.com</a>> wrote:<br>>
<br>>> I've just set up a new two-node GFS cluster on a CORAID sr1520<br>>> ATA-over-Ethernet.  My nodes are each quad dual-core Opteron CPU<br>>> systems with 32GB RAM each.  The CORAID unit exports a 1.6TB
 block<br>>> device that I have a GFS file system on.<br>>><br>>> I seem to be having performance issues where certain read system<br>>> calls take up to three seconds to complete.  My test app is bonnie++,
<br>>> and the slow-downs appear to be happen in the "Rewriting" portion of<br>>> the test, though I'm not sure if this is exclusive.  If I watch top<br>>> and iostat for the device in question, I see activity on the device,
<br>>> then long (up to three second) periods of no apparent I/O.  During<br>>> the periods of no I/O the bonnie++ process is blocked on disk I/O, so<br>>> it seems that the system it trying to do something.  Network traces
<br>>> seem to show that the host machine is not waiting on the RAID array,<br>>> and the packet following the dead-period seems to always be sent from<br>>> the host to the coraid device.  Unfortunately, I don't know how to
<br>>> dig in any deeper to figure out what the problem is.<br>>><br>>> Below are strace and tcpdump snippets that show what I'm talking<br>>> about.  Notice the time stamps and the time spent in system calls in
<br>>> <> brackets after the call.  I'm quite far from a GFS expert, so<br>>> please let me know if other data would be helpful.<br>>><br>>> Any help is much appreciated.<br>>><br>>> Thanks!
<br>><br>> --<br>> Jayson Vantuyl<br>> Systems Architect<br>> *Engine Yard*<br>> <a href="mailto:jvantuyl@engineyard.com">jvantuyl@engineyard.com</a> <mailto:<a href="mailto:jvantuyl@engineyard.com">jvantuyl@engineyard.com
</a>><br>><br>><br>> ------------------------------------------------------------------------<br>><br>> --<br>> Linux-cluster mailing list<br>> <a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com
</a><br>> <a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a><br><br>--<br>Linux-cluster mailing list<br><a href="mailto:Linux-cluster@redhat.com">Linux-cluster@redhat.com
</a><br><a href="https://www.redhat.com/mailman/listinfo/linux-cluster">https://www.redhat.com/mailman/listinfo/linux-cluster</a><br></blockquote></div><br>