I was (finally) able to reproduce the failure on Windows Service Pack 3 here (was not able to on Service Pack 1, but I also had to change the block size). It looks like it wasn't failing with ~20-30 simultaneous requests - but I see failures (actually I just see the reconnects in /proc/fs/cifs/Stats) at 39 simultaneous writes in flight to Windows XP service pack 3 (server). To get enough write requests in flight (39? or at least more than 30) at one time to get it to fail I had to set write size to 4096 (wsize=4096 on mount) and relatively large application write size (6MB rather than 1MB) in tests. For example: sudo dd if=/dev/zero of=/mnt/bigfile bs=6MB count=250 I think the patch I suggested earlier will fix it - but need to do some testing. I haven't seen stability problems with it but would like to test it more. On Tue, Jun 28, 2011 at 11:01 PM, Steve French <smfrench@xxxxxxxxx> wrote: > I checked more carefully and the more likely reason it worked was that > that client system was running a version (an early version) of my patch > The patch restricts the number of simultaneous > operations to what the server reports as maxmpx. I will run a better > before/after comparison tomorrow. > > On Tue, Jun 28, 2011 at 3:38 PM, Steve French <smfrench@xxxxxxxxx> wrote: >> I tried to recreate this to Windows XP today, but instead of mounting to a >> normal WindowsXP desktop, mounting to a VM - a Windows XP Professional >> test system (service pack 1 level system) running in virtualbox, and >> was not able to >> get it to fail even though number of simultaneous requests exceeded 10. >> >> Before, when mounting to a normal Windows XP desktop, I had been able to >> make it fail faster with wsize=8192 and wsize=4096 on the cifs mount, >> but not mounting to this vm. >> >> I am going to try updating the WindowsXP to a newer service pack level to >> see if that is what changed and also run with tracing off to see if it >> recreates faster. >> >> What service pack level of Windows XP were you running? >> >> On Mon, Jun 27, 2011 at 9:23 PM, Steve French <smfrench@xxxxxxxxx> wrote: >>> I don't think you should need to set max_pending below 9 (I am trying >>> to determine >>> if 10 is ok, or whether XP reserves one for async oplock breaks) since this is >>> a per-socket limit. We had a long discussion about this at MS Friday >>> but the questions were about whether it was a number of requests >>> per-pid (per process) >>> limit on each connection or whether it was across the connection (socket, as I >>> expect, and as the documentation implies). In any case, the number of other >>> connections from other network clients to the machine should not >>> affect the number >>> of simultaneous operations on this Linux client's one connection to XP (which >>> looks to be 10 or 9 depending on how you read the documentation). >>> >>> On Mon, Jun 27, 2011 at 6:34 PM, Shane McColman >>> <smccolman@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> >>>> Kernel errors have dropped significantly (only 2 during the day today). No >>>> errors in copying files. >>>> >>>> Thanks for all the help. I really do appreciate it. >>>> >>>> Shane >>>> >>>>>I verified that Windows XP only allows a max of 10 connections as set by >>>>>Microsoft. This machine already has 5 connections from the 5 pieces of >>>>>equipment here, so I'm left with 5. For this reason I set >>>>>cifs_max_pending=4 >>>>>to stay on the safe side. That was at 9:30 this morning and have not had >>>>>an >>>>>error since. I'll check again on Monday and give you an update. >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> >>> >>> -- >>> Thanks, >>> >>> Steve >>> >> >> >> >> -- >> Thanks, >> >> Steve >> > > > > -- > Thanks, > > Steve > -- 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
