On Tue, Feb 05, 2013 at 08:54:31AM -0800, Klise, Steve wrote:
This is a complete stab in the dark, but a command you can try to run is mbstat. My guess is CIFS may have been starved from ontap doing what it does, or there is a bug for some sort of memory leak.
I have experienced something similar to this a long time ago with DOT 7.3x (but not with the error you noted). I would start losing ICMP to the filer, then it would just give up and panic.. Turned out I would monitor it via mbstat, and could predict how long the filer would stay up based on buffers free....
Again, just a stab in the dark. I would open a support case on it.
Thanks, Klise. We have a support case opened and hopefully will get some direction.
Checked mbstat output, and at least right now I don't see anything that jumps out at me:
ed-str-napc2-p2> mbstat System pool small bufs: free 13440+2254 (out of 15744), borrowed 0 mallocs 0, drains 0 (success 0), waits 0, drops 0 System pool large bufs: free 29056+6022 (out of 81123), borrowed 12103 mallocs 153898203, drains 0 (success 0), waits 0, drops 0 Private pool c0a: free 0+8 (out of 10340) mallocs 0, drains 0 (success 0), waits 0, drops 2 Private pool c0b: free 0+7 (out of 10340) mallocs 0, drains 0 (success 0), waits 0, drops 2
267322 total mbufs 66760 MT_DATA 200562 MT_FREE Descriptor mbuf: total 267272, mallocs 0, drops 0 Old style mbuf: total 50, mallocs 55671, drops 0 nfs: request 0 ip reassembly: 0 frags, 0 pkts
Perhaps something will jump out to a more experienced eye. The numbers here don't look particularly far off from the numbers on the other controller in this CFO group. However, that controller hasn't had this issue occur and we *had* restarted the CIFS service on the "bad" controller shortly before running the mbstat command so the numbers may look different while the issue is occurring.
Thanks, Ray
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Monday, February 04, 2013 9:40 PM To: toasters@teaparty.net Subject: NT_STATUS_NO_MEMORY
Anyone ever encountered this error when attempting to access a CIFS share on an ONTAP 8.0.x system? ("NT_STATUS_NO_MEMORY").
We encountered reports from users of intermittent failures to connect to CIFS shares. From Windows hosts, things would just time out. From Samba clients, the above NT_STATUS_NO_MEMORY error was the result.
The "fix" ended up being to restart the CIFS service on the system, but wondering what the true root cause here might be. I'm unsure how accurate the error returned by the Samba client is -- in any case there doesn't appear to be a way to query memory utilization on the NetApp.
Thanks, Ray