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. -- Thanks, Steve -- 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
