[OpenIndiana-discuss] CIFS performance issues

[James Carlson]

Robin Axelsson wrote:
> On 2012-01-24 16:52, Gary Mills wrote:
>> On Tue, Jan 24, 2012 at 04:39:42PM +0100, Robin Axelsson wrote:
>>>>> ifconfig -a returns:
>>>>> ...
>>>>> e1000g1: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>   mtu
>>>>> 1500 index 2
>>>>>          inet 10.40.137.185 netmask ffffff00 broadcast 10.40.137.255
>>>>> e1000g2: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>   mtu
>>>>> 1500 index 3
>>>>>          inet 10.40.137.196 netmask ffffff00 broadcast 10.40.137.255
>>>>> rge0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>   mtu
>>>>> 1500
>>>>> index
>>>>> 4
>> Do you really have two ethernet ports on the same network?  You can't
>> do that without some sort of link aggregation on both ends of the
>> connection.
> I don't see why not. I've done this before and it used to work just
> fine. These are two different controllers that work independently and I
> do it so that the VM(s) could have its own NIC to work with as I believe
> the virtual network bridge interferes with other network activity.

It's never worked quite "right" (whatever "right" might mean here) on
Solaris.

If you have two interfaces inside the same zone that have the same IP
prefix, then you have to have IPMP configured, or all bets are off.
Maybe it'll work.  But probably not.  And was never been supported that
way by Sun.

> If we assume that both ports give rise to problems because they run
> without teaming/link aggregation (which I think not) then there wouldn't
> be any issues if I only used one network port. I have tried with only
> one port and the issues are considerably worse in that configuration.

That's an interesting observation.  When running with one port, do you
unplumb the other?  Or is "one port" just an application configuration
issue?

If you run "/sbin/route monitor" when the system is working fine and
leave it running until a problem happens, do you see any output produced?

If so, then this could fairly readily point the way to the problem.

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>