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

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

[Steve French]

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.

As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in
the Windows registry solves this.

The cifs async write code does increase large file copy speed
dramatically (more than 15% in most environments) - but we are working
through how to handle the Windows7/WindowsVista problem to see if
there are workarounds.

-- 
Thanks,

Steve

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

[Jeremy Allison]

On Tue, Sep 27, 2011 at 04:36:22PM -0500, 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.
> 
> As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in
> the Windows registry solves this.
> 
> The cifs async write code does increase large file copy speed
> dramatically (more than 15% in most environments) - but we are working
> through how to handle the Windows7/WindowsVista problem to see if
> there are workarounds.

Have you notified the Microsoft engineers about this ? I can
give you the right names to bug...

Jeremy.

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

[Steve French]

On Tue, Sep 27, 2011 at 6:01 PM, Jeremy Allison <jra-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> Have you notified the Microsoft engineers about this ? I can
> give you the right names to bug...

Yes.

It is trickier than I expected to reproduce (since we send large
writes, not all network interfaces are fast enough to support 127K
write size * 10 requests).


-- 
Thanks,

Steve

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

[Suresh Jayaraman]

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?

Thanks
Suresh

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

[Jeff Layton]

On Wed, 28 Sep 2011 11:17:25 +0530
Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> 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 ?

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

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

[Steve French]

On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Wed, 28 Sep 2011 11:17:25 +0530
> Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> 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

Re: 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> > On Wed, 28 Sep 2011 11:17:25 +0530
> > Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> 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-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

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

[Suresh Jayaraman]

On 09/29/2011 01:24 AM, Jeff Layton wrote:
> On Wed, 28 Sep 2011 13:27:33 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
>>> On Wed, 28 Sep 2011 11:17:25 +0530
>>> Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> 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

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

[Jeff Layton]

On Thu, 29 Sep 2011 10:42:52 +0530
Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> wrote:

> On 09/29/2011 01:24 AM, Jeff Layton wrote:
> > On Wed, 28 Sep 2011 13:27:33 -0500
> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 
> >> On Wed, Sep 28, 2011 at 7:06 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> >>> On Wed, 28 Sep 2011 11:17:25 +0530
> >>> Suresh Jayaraman <sjayaraman-IBi9RG/b67k@public.gmane.org> 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.
> 

Yeah, I always sort of consider -EIO to be more or less a "catch-all"
error. Report that when you can't translate it to any other allowable
error. -EREMOTEIO is basically -EIO on a remote host -- that seems like
a more reasonable representation of the problem.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

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

[Shirish Pargaonkar]

On Tue, Sep 27, 2011 at 4:36 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

If this is a problem with Windows Vista and Windows 7, it is likely
to be a problem with Windows 2008 Server as well.
Basically Windows server starting Vista perhaps?

>
> As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in
> the Windows registry solves this.
>
> The cifs async write code does increase large file copy speed
> dramatically (more than 15% in most environments) - but we are working
> through how to handle the Windows7/WindowsVista problem to see if
> there are workarounds.
>
> --
> Thanks,
>
> Steve
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[Steve French]

On Wed, Sep 28, 2011 at 4:30 AM, Shirish Pargaonkar
<shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Sep 27, 2011 at 4:36 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>
> If this is a problem with Windows Vista and Windows 7, it is likely
> to be a problem with Windows 2008 Server as well.
> Basically Windows server starting Vista perhaps?

I have not been able to reproduce it against Windows 2003
or Windows 2008 server yet, but plan some experiments.
If you have additional test data on this let me know.


-- 
Thanks,

Steve

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

[Jeff Layton]

On Wed, 28 Sep 2011 13:28:38 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Wed, Sep 28, 2011 at 4:30 AM, Shirish Pargaonkar
> <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On Tue, Sep 27, 2011 at 4:36 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
> >
> > If this is a problem with Windows Vista and Windows 7, it is likely
> > to be a problem with Windows 2008 Server as well.
> > Basically Windows server starting Vista perhaps?
> 
> I have not been able to reproduce it against Windows 2003
> or Windows 2008 server yet, but plan some experiments.
> If you have additional test data on this let me know.
> 
> 

Most likely, those servers report a MaxMpx >= 50. The only real
question I have is what maxmpx vista and 7 report. If it's <50 then
this is likely our bug, not theirs. It seems quite correct for the
server to return an error if the client exceeds that limit.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

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

[Steve French]

On Wed, Sep 28, 2011 at 2:56 PM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Wed, 28 Sep 2011 13:28:38 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Wed, Sep 28, 2011 at 4:30 AM, Shirish Pargaonkar
>> <shirishpargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On Tue, Sep 27, 2011 at 4:36 PM, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

For servers other than Windows 7 and Windows Vista, we have
not been able to reproduce the problem, so Windows 2003 and Windows 2008
are probably ok.  I was also unable to reproduce this to Samba or Windows XP

But for mounts to Windows 7 or Windows Vista from Linux cifs for 3.0
kernel or later,
two workarounds for this Windows problem have been found:

1) As Pavel discovered, increasing MaxWorkItems to 4096 in the Windows
registry solves this.
2) Or to workaround this on the Linux client, load the cifs kernel
module with a lower limit on the simultaneous requests per connection
ie
     "modprobe cifs cifs_max_pending=10"
(it would default to 50)





-- 
Thanks,

Steve

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

[Jeff Layton]

On Tue, 27 Sep 2011 16:36:22 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
> 
> As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in
> the Windows registry solves this.
> 
> The cifs async write code does increase large file copy speed
> dramatically (more than 15% in most environments) - but we are working
> through how to handle the Windows7/WindowsVista problem to see if
> there are workarounds.
> 

This is seems likely to be a cifs.ko bug -- it does not respect the
MaxReq parm that the server sends in the negotiate and instead uses a
hardcoded limit of 50 requests (which is tunable via module parm).

What value is the server sending in the NEGOTIATE? Ensuring that
cifs.ko doesn't exceed that value seems like a worthwhile endeavor.
This is likely to be even worse soon when the async read patches are
merged.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

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

[Steve French]

On Wed, Sep 28, 2011 at 7:00 AM, Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org> wrote:
> On Tue, 27 Sep 2011 16:36:22 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>>
>> As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in
>> the Windows registry solves this.
>>
>> The cifs async write code does increase large file copy speed
>> dramatically (more than 15% in most environments) - but we are working
>> through how to handle the Windows7/WindowsVista problem to see if
>> there are workarounds.
>>
>
> This is seems likely to be a cifs.ko bug -- it does not respect the
> MaxReq parm that the server sends in the negotiate and instead uses a
> hardcoded limit of 50 requests (which is tunable via module parm).
>
> What value is the server sending in the NEGOTIATE? Ensuring that
> cifs.ko doesn't exceed that value seems like a worthwhile endeavor.
> This is likely to be even worse soon when the async read patches are
> merged.

Yes, the client should not be exceeding the limit, but more testing
is needed of my earlier patch for that.


-- 
Thanks,

Steve