adding and removing drivers from nexentastor is not easy.

but if the system is telling you there is an updated driver, you should be able to upgrade to get the new driver..

this does need to be done on the command line but it is very easy..

ssh root@ipaddress

nmc

setup appliance upgrade

it will then ask you some questions..then reboot

The system's not telling me that it needs an updated driver, I just read on one of the threads in the forum that in many cases, setting the MTU to 7000 for jumbo frames requires a NIC driver update. I set mine to 7000, and found that the NIC was no longer communicating. I set it back to 1500, and it started working again. I made sure that jumbo frames was enabled on my switch, as well as the other machine on my network.

So, if I take what you said a step further, if I set the MTU to 7000, and then run the 'setup appliance upgrade' command, would it update the driver?

It's not a major issue at this point if it doesn't work. I'm getting decent performance using 1500 on the iSCSI NIC. I think I saw up to 40MB/sec transfer rate when running a folder sync from my server to Nexenta. That equates to roughly 320mbps on a gigabit network. I figured if it weren't going to be incredibly difficult, I'd try to squeeze every bit of performance out of it I could get.

Thanks!

Scott

we typically set 9000 for jumbo frames.

so my point on updating is that if there is an updated driver, you will get it in an upgrade. otherwise we will have to work though to try and find the right package in the repo that may have what you are looking for. It is kind of like swatting a bug with a house.. but easy.

I just did the upgrade to 3.1.3, so I can try it again and see if the driver updated. Otherwise, I can live with what I'm running now. That's how I threw my back out - swatting bugs with houses. :)

For future reference: The topic starter posts an incorrect error message. The system says "Warning, changing mtu MAY require driver re-load! Network Interface(s) could be re-initialized".

So it will restart the driver. That's all. It does not tell you the driver needs to be updated. Linda totally went into the wrong direction as a consequence.

There is a known bug with the e1000g driver that setting the MTU to 9000 on a single interface, can (on my system "will") actually modify the MTU on all interfaces that are controlled by this driver. A "show interface" will tell you that the interface that was not modified, is still on mtu 1500 but in reality it's not and traffic to this interface will stop.

Only a revert to mtu 1500 on the interface that was set to 9000 will re-initialize all related interfaces back to 1500 and traffic will start flowing again. This is a documented bug in OpenSolaris, not something Nexenta's fault. It's still around in v3.1.3.5

It does not always happen. But on my system it does. MTU 9000 works fine, but then the interfaces that i want to stay on 1500 just stop working.

The wierd thing is, setting an interface to mtu 9000 should not make it stop working with lower packet-sizes. One should still be able to talk with hosts that are on mtu 1500. On the OpenSolaris version that Nexenta uses however, it seems a one-thing affair: Either 9000 or 1500, all or nothing. On my system, when i'm on 9000, i can only talk to other hosts that are on 9000 too, on any given interface controlled by the e1000g driver, regardless if other interfaces are set to 1500. (looking at the interfaces with dladm, it shows that all the related interfaces are on 9000, even though the NMC says 1500)

Now, if i avoid using the NMC, and do thing in the UNIX shell, it works fine. I can set an interface to mtu 9000 without affecting the other interfaces the driver controls.

On my system: e1000g2 is the interface for IP Storage, and should be on mtu 9000 e1000g3 is the management interface and should stay on mtu 1500.

If i do a: ifconfig e1000g2 unplumb dladm set-linkprop -p mtu=9000 e1000g2 ifconfig e1000g2 plump up

then all is fine. Only the e1000g2 interface is set to 9000 and the other interface, controlled by the same driver, stays at 1500 and keeps working.

This makes me believe there is a bug in the NMC of Nexenta 3.1.3.5