[OpenIndiana-discuss] CIFS performance issues

[James Carlson]

On 01/27/12 07:51, Robin Axelsson wrote:
> On 2012-01-25 21:50, James Carlson wrote:
>> By default, the first IP layer object created on a given datalink layer
>> object has the same name as that datalink layer object -- even though
>> they're distinct ideas.  The second and subsequent such objects created
>> get the somewhat-familiar ":N" addition to the name.  It's sometimes
>> helpful to think of that first object as being really named "e1000g1:0"
>> at the IP layer, in order to keep it distinct from the "e1000g1"
>> datalink layer item.
> 
> This sounds like an implementation of the OSI model which separates the
> datalink layer from the network layer.

Yes.  The design (since Solaris 2.0) has always been internally a bit
more deliberately layered, but during OpenSolaris development we put a
lot of work into making the distinctions more visible in the
administrative interfaces, because they're actually fairly useful when
it comes to virtualization and other new functions.

>  When speaking of blurred lines,
> it seems that the line between the network layer, transport layer and
> session layer (as specified in the OSI model) is also quite blurry.

Network and transport are fairly clear (though ICMP is sort of a sticky
bit).  Session is basically absent for TCP/IP.

> In NAT mode the VirtualBox hypervisor acts as a virtual router that sits
> between the IP stack of the host and the VMs. It has its obvious
> limitations as you have pointed out which is why I don't use this mode.
> This mode also has (or at least had in prior versions of VirtualBox)
> stability/performance issues.

OK

>> Back in the bad old days of BOOTP, clients were in fact forced to use
>> hardware (MAC) addresses for identification.  That's still the default
>> for DHCP, just to make things easy, but a fancy client (such as the one
>> in OpenIndiana) can create client identifiers from all sorts of sources,
>> including thin air.
> 
> I guess that this ClientID feature is only used by more advanced
> routers, because all my machines (virtual and physical) are identified
> by a given MAC address in the router. Or maybe it is capable of ClientID
> and I'm not aware of it, the router documentation is mum about this
> feature though.

As I said, using the MAC address to construct a client identifier is
generally the default, so it's not at all surprising that this is what
you see.  The point is that it's not the only possibility.

>> You have to tell ifconfig what you want to do.  If you want to modify
>> the separate IPv6 interfaces, then specify "inet6", as in:
>>
>>     ifconfig e1000g0 inet6 unplumb
> 
> Ok. When I plumb/unplumb a connection with ifconfig, will this
> (un)plumbing be permanent or only be in effect until next reboot or
> power cycle?

It's non-permanent.  It affects only the running system.

> I would expect that this plumbing configuration is in some
> /etc/<config> file somewhere...

Yes.  If you're running with the old-style start-up scripts, then the
existence of /etc/hostname.XXX causes interface "XXX" to be plumbed for
IPv4 and for the contents of that file to be used as the arguments and
options to ifconfig.  A similar thing is true for /etc/hostname6.XXX,
but for IPv6.  And if /etc/dhcp.XXX exists, the interface is plumbed and
DHCP is run.

Things changed quite a bit with both NWAM and ipadm.  The latter
provides both transient and permanent configuration features, and no
longer relies on the /etc/hostname.* files.

>> In modern -- CIDR -- IPv4, you don't normally refer to a subnet mask as
>> something like 255.255.255.128, but rather as a prefix length, like
>> "/25".  Besides being more compact, the prefix length notation avoids
>> dumb (and pointless) mistakes that occur when someone accidentally
>> specifies non-contiguous mask bits.
> 
> Ok, so I assume that the /n means that the /n/ least significant
> consecutive bits are 0 in the network mask.

No.  It means that the "n" most significant bits are 1, and the "32-n"
least significant bits are 0.  So, "/24" is 255.255.255.0.  "/8" is
255.0.0.0.  "/28" is 255.255.255.240.

> So that means I'm no longer
> able to specify network masks such as 170.85.144.70 where for example
> 144 in binary form is 10010000, i.e. that the zeroes in the mask are not
> consecutive/contiguous as there are ones in between.

For IPv4 may still be able to use non-contiguous masks, but they were
never a rational choice at all -- anywhere.  And with certain routing
protocols, they simply didn't and could not work.  They're a definite
case of "so, what exactly were you trying to do?"

All that matters is the number of bits that are set, so having them be
contiguous is no loss of functionality.

> So I understand this restriction is enforced so as to prevent the
> accidental creation of subnets that not mutually exclusive, i.e that
> overlap each other.

That's part of it.  Certain protocols (e.g., BGP) rely on having the
bits be contiguous.  Aiding human understanding is certainly another part.

But, at least as far as I'm concerned, the crucial fact is that making
them non-contiguous buys you no added functionality at all.

>>> When I shut down the virtual machine, the e1000g2 connection disappeared
>>> from 'ifconfig -a'. So it seems that the VM somehow blocked/prevented
>>> ifconfig to apply the unplumbing and once the VM was shut down the
>>> unplumbing kicked in first then.
>> That's weird.  I don't know enough about VirtualBox, though, to know how
>> or why that would happen.  I don't think it should.  It kinda sounds
>> like a bug.
> 
> Yes, there is a bug somewhere, the question is which part of the system
> is at fault here; VirtualBox and the vboxflt driver or OpenIndiana and
> its IP stack?

It's almost impossible to tell from the description.  I think that using
dtrace to watch the operation would be interesting.

But my first guess would have to be strangeness in vboxflt, because I
can say I've never seen that sort of behavior out of regular
Solaris/OpenSolaris/OpenIndiana.

> I have now tortured my system for a while and I have not yet been able
> to reproduce these freeze-ups that I used to have so it seems that
> everything is fine now. I will continue to keep an eye on this for a few
> weeks though.

That's encouraging.

> I'm happy to have received responses from someone as knowledgeable such
> as yourself and I appreciate the time you have taken to help me (and
> hopefully others in this mailing list) with this issue!

Good luck ...

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