[OpenIndiana-discuss] CIFS performance issues

[Robin Axelsson]

On 2012-01-27 16:45, James Carlson wrote:
> Robin Axelsson wrote:
>> On 2012-01-27 15:32, James Carlson wrote:
>>> What NWAM is supposed to do is configure only one usable interface
>>> (guided by user selection criteria) for the system.  The fact that you
>>> got multiple interfaces configured is indeed an anomaly, and one I can't
>>> explain.  I don't know how you got there in the first place.  It
>>> shouldn't have happened.
>> I don't agree with you on that. Many motherboards come with dual
>> ethernet ports (i.e. dual NICs, I have counted the chips myself) and it
>> is not uncommon with laptops with one wired ethernet interface and a
>> wireless one. So as you said, there is the potential risk of
>> interference between the two interfaces even though one may not even be
>> connected.
> Don't agree how?

That systems with multiple interfaces are an anomaly, but maybe that's 
not what you meant.

>
> NWAM's original mission in life was to make sure that only one interface
> was configured at a time, regardless of how many might be available.
> I'm pretty darned sure that's true, because I was involved in that project.
>
> That's sort of the whole point.  NWAM looks over the available
> interfaces, figures out which ones are usable, then applies a set of
> policies to determine which one of all of those will be used.  It then
> disables the others and properly configures the rest of the system to
> use that one chosen interface.  If conditions change, then it
> reevaluates the situation.
>
> The canonical example would be a laptop with wired and wireless
> interfaces.  The default rule would be to use wired if it's connected
> and working, and otherwise use the wireless interface.  Not both at any
> one time.
>
> Things changed a bit in the next incarnation of NWAM, and I wasn't as in
> touch with that one.  However, the fundamental design goal of producing
> a working configuration -- and avoiding known unworkable configurations
> -- wasn't abandoned.  So, what you saw was either a bug or a
> misconfiguration of some sort, and you'd need to find someone who knows
> more about that second NWAM.
>
>>> That sounds backwards to me.  If a buggy driver exists, then the bugs
>>> should be fixed, or the driver should be discarded.  There's no reason
>>> on Earth to have some other bit of software "warning" users about
>>> someone else's software design failures, whether real or otherwise.  At
>>> best, that other software would just become a repository of uselessly
>>> independent misjudgment -- as new, unknown buggy drivers are written and
>>> old ones are repaired.
>>>
>> True, but what do you do when *all* you've got is a buggy driver that
>> _may_ work well on your system? Either you use the driver or you go get
>> a network card that is proven to work well with Solaris/OpenIndana. The
>> thing is that a substantial part of the development of OI depends on the
>> charity of willing developers and their spare time, so you have to make
>> the best out of what you have at your disposal.
> I think we have differing viewpoints on system architecture.
>
> To me, it would be a very poor design choice to embed detailed knowledge
> of some driver writer's parental marital status into an independent part
> of the system.
>
> If all compromised drivers exposed a "I'm potentially garbage" flag,
> then, fine, that independent part could read that flag and do whatever
> it wants based on it.  But merely reading the letters "rge" and deciding
> to impugn the connection based on some history or accusations strikes me
> as untenable.
>

The only opinion that I have is that it should work and reliably so. The 
rge driver is apparently buggy and that's what people say about it in 
mailing lists. It is included with the OI distribution/repository. If I 
had the time and knowledge I would try and fix it myself but 
unfortunately I don't.

I have told myself to get to learn dtrace someday but I guess that I 
will have to get through the "Solaris Internals" to even be able to 
understand the output it generates.