Mounts to Windows 7 and "out of memory" or "insufficient server resources"

[Jeff Layton]

On Wed, 28 Sep 2011 13:27:33 -0500
Steve French <smfrench at gmail.com> wrote:

> On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton at samba.org> wrote:
> > On Wed, 28 Sep 2011 11:17:25 +0530
> > Suresh Jayaraman <sjayaraman at suse.com> wrote:
> >
> >> On 09/28/2011 03:06 AM, Steve French wrote:
> >> > FYI - The cifs async write in 3.0 seems to exacerbate problems running
> >> > out of memory (apparently) on the Windows 7 system (running as a
> >> > server) after a large file copy to the server completes.   I have been
> >> > able to reproduce the same problem on Windows Vista Service Pack 2
> >> > (which is a good news/bad news story since my earlier testing on
> >> > Windows Vista showed hangs on some requests rather than returning out
> >> > of memory).  Does not seem to be a problem with any of the Windows
> >> > server versions just Windows 7 and Vista so far.
> >>
> >> The last time when I encountered this, cifs client was reporting "Cannot
> >> allocate memory" a.k.a -ENOMEM error. But, it is actually a
> >> NT_STATUS_INSUFF_SERVER_RESOURCES error from Server being mapped to
> >> -ENOMEM. I found this mapping confusing atleast initially. Is this
> >> mapping correct?
> >>
> >> Not sure do we have a POSIX equivalent of
> >> NT_STATUS_INSUFF_SERVER_RESOURCES? Should we map it to a error code that
> >> is more obvious?
> >>
> >
> > Maybe -EREMOTEIO ?
> 
> The mapping of NT_STATUS_INSUFFICIENT_SERVER_RESOURCES to posix error
> ENOMEM appears to be correct for multiple reasons.  Windows itself maps it this
> way when mapping from NT STATUS to DOS errors. For example, on subsequent
> requests, I see server returning DOS (!) error for error_no_memory on some
> types of SMBs and NT error insufficient_server_resources on others.
> 

I don't know...

ENOMEM has clear connotations -- it tells you the machine (client) is
unable to allocate memory. You might be able to stretch that to mean
that the client is unable to allocate some other resource, but in this
case it's the *server* not the client that's reporting the problem.

It seems probable that DOS error codes just lacked anything better for
this mapping. In our case though, -EREMOTEIO seems like a better
mapping as it makes it clear that it's the server that can't allocate
resources, not the client.

-- 
Jeff Layton <jlayton at samba.org>