is this windows 7?

Yes, im mounting the CIFS share on Windows 7.

Have tested it a bit more today and even turned of the CIFS share entirely without any change in behavior. The server losses network connectivity within 10-15 min of beeing booted as long as there is network activity against it.

Can I have you file this as a bug? I actually am seeing this dropping of network connection several places today and it is only with windows 7 clients. I would like this to get into the support queue for a permanent fix.

NMV bottom banner, click on "Found a bug?"

Hopefully we can find a workaround or root cause. If there is anyone reading this and seeing the same problem please report it to support@nexenta.com

thanks.

Just done a complete reinstall and currently testing filetransfer from OS X (Snow Leopard) on a CIFS mount. No issues so far but only got about 30 min of data. Will redo Win 7 tests tomorrow and report bug if i still get the same network issues then.

Tested with both Windows 7 and OS X CIFS client. No issues with OS X, but 5-10 min after Win 7 client starts transfering files the nexenta server looses network and only way i found to restore network is a full reboot.

@Linda: Tried to file this as a bug, but as i´m on a community license i only got "Contact Not Registered - Action Required" as an respons.

actually i filed this as a bug. thanks for trying :)

i am keeping my eye on this, will advise.

hey can you run snoop on the server while testing?

snoop -d interfacename windowshostname -o outputfile

we should be able to see what's not working.

Ok, running it now. File is going to be fairly large, but i guess were only interested in the end of it...

yep, maybe you can get me the tail?

Attached are the last 1000 lines from

snoop -d gani0 -o win-7-cifs.log 10.0.0.4

As you can see there's quite a few packets sent before things go bad

nice, i like when i can see the problem. My favorite cifs engineer is out until monday. I would like to run this by him.

as you are testing, are you reading from the ns and writing to the windows box? or running some io simulator?

also, what does the pool look like on the ns?

Testing by writing large 500+ MB files from the win box to ns. Below is the output from zpool status

pool: syspool state: ONLINE scan: none requested config:

    NAME        STATE     READ WRITE CKSUM
    syspool     ONLINE       0     0     0
      c1d0s0    ONLINE       0     0     0

errors: No known data errors

pool: tank state: ONLINE scan: none requested config:

    NAME        STATE     READ WRITE CKSUM
    tank        ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        c0d0    ONLINE       0     0     0
        c2d0    ONLINE       0     0     0
        c3d0    ONLINE       0     0     0

can you see the size of the file at the point it stops? there is an adjustment that is made at 500 MB

Haven´t got excat numbers but judging from the explorer UI i´v had one failure at 600MB and one at 1.3GB

And just to clarify, sometimes i can get several 500+MB files across before it fails.

Any chance you can get us a binary snoop of this problem? i.e.

  snoop -o win7stop.snoop host $my_win7_client_name

If you like, you can examine it with wireshark and perhaps save just the last 1000 frames or so to a new file and send that instead of the huge original capture file.

Thanks, Gordon

gordon,

there is a basic snoop in this thread...

I need a binary snoop (the text representation omits too many details) Filtering the the client of interest is helpful, as is saving only the last 1000 frames or so. To do that, open the snoop file in wireshark, select the last 1000 frames, then save as (selected frames)...

Here's to hoping this will be a case of better late then never...

Attached is a snoop of the last 1 000 packets of a transfer from Win 7 (10.0.0.9) to Nexenta 3.1.1 (10.0.0.6) that killed the Nexenta network connection. The transfer was a single 8GB file.

Thanks for providing a snoop capture. I examined it, and the last few frames are SMBwrite responses, followed by some TCP retransmit frames. At that point, the client appears to be sending nothing back. I would look next at what's happening on the client.

Hm, on the client side I see retransmissions both ways then a lot of ARP traffic. The odd bit here is that at the client retains network connectivity after this exchange while the Nexenta server losses all network connectivity and needs to be rebooted to restore it. As said before, doing the same file transfers with my Mac as client works flawlessly.

Attached is both server and client snoop if it's any help.