On Wed, 28 Sep 2011 13:27:33 -0500 Steve French <smfrench@xxxxxxxxx> wrote: > On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > > On Wed, 28 Sep 2011 11:17:25 +0530 > > Suresh Jayaraman <sjayaraman@xxxxxxxx> 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@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
