ggate still broken on 6.2-RC1 for amd64.
dgilbert at dclg.ca
Mon Dec 11 09:32:42 PST 2006
>>>>> "Craig" == Craig Boston <craig at feniz.gank.org> writes:
Craig> On Mon, Dec 11, 2006 at 02:47:41AM -0500, David Gilbert wrote:
>> That doesn't square with my experience. Although bigger buffers
>> could be involved in a performance problem, what we're dealing with
>> here is a _zero_ traffic situation. It seems that it works enough
>> for tasting to be successful, but any significant load wedges it
Craig> The problem I observed was also a zero traffic situation. A
Craig> quick way to test is to do something like this (assuming you
Craig> don't care about the contents of the device!)
Craig> dd if=/dev/zero of=/dev/ggateX bs=1m
Craig> and watch the network traffic to see what happens. When I ran
Craig> into it, small block sizes worked fine, but anything bigger
Craig> than the send buffer size would cause the entire ggate device
Craig> to wedge with zero traffic. The ggatec logs in my mail archive
Craig> say 128k, which itself is a little odd because I thought GEOM
Craig> broke big transfers into 64k chunks.
Craig> In any case, ggatec got stuck in a loop getting EAGAIN from
Craig> send(), so the packets never made it out to the wire.
Craig> However checking my mail archive also indicates that was a year
Craig> ago so chances are this is a different problem. The symptoms
Craig> just sounded a little familiar.
Urm... what would be the transfersize that the filesystem prefers to use?
Also, what trasnfersize does the gmirror sync use?
|David Gilbert, Independent Contractor. | Two things can be |
|Mail: dave at daveg.ca | equal if and only if they |
|http://daveg.ca | are precisely opposite. |
More information about the freebsd-stable