On 09/29/2011 01:24 AM, Jeff Layton wrote: > 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. Exactly. I have had customers with whom I had hard time explaining this is not a client side problem because they argue that it is a client side memory allocation error and the client should be fixed. I couldn't find any standard text where the current mapping is documented. > 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. > -EREMOTEIO sounds very close me. Atleast, it communicates it is a remote server side issue and not a client side issue. -Suresh -- 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
