On Fri, May 6, 2011 at 6:41 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Fri, 6 May 2011 11:01:52 +0400 > Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > >> 2011/5/6 Steve French <smfrench@xxxxxxxxx>: >> > Two reserved slots: 1 for oplock break, 1 for echo. >> >> What's if we need to send oplock break for two files in almost the same time? >> >> > Note that if maxmpx is set to 2 on negotiate, we also have to disable >> > oplock (echo + 1 pending open request would max out our maxmpx) >> >> What's if maxmpx is set to 1? According to the link (that I posted >> above) it is a possible situation. >> >> Note that now we don't count block locking command, but the spec >> doesn't tell anything about it - so, I think we should count them too. >> > > Ditto. The blocking lock code is a mess anyway -- that really needs a > fundamental re-think. > >> May be we should drop any exceptions, count all types of requests and >> move to smth like priority queue? In this case we can use three kind >> of lists and put echo requests into the highest priority list - e.g. >> "3", oplock break requests - "2", and all other requests into the >> priority "1" list. Or we can use only one double-linked list and put >> all echo and oplock break requests to the head, and all other requests >> - to the tail. >> >> Thoughts? >> > > A priority queue doesn't really help here. What if you already have > maxmpx calls in flight and suddenly need to send an oplock break? > You'll just be stuck. > > I think all you really need here is a flag for the slot allocator that > tells whether some calls are allowed to dip into the emergency pool, > and keep a couple of slots in reserve for echoes and oplock breaks like > Steve suggests. > > In practice, there's probably no reason to have more than one echo in > flight, and we could modify the echo code not to send one when there's > already one that the server hasn't responded to. > > If the server sends back a maxmpx value less than 2 we should probably > fail the mount. Less than 3, and we should disable oplocks. Setting maxmpxcount to 1 could be a server bug - IIRC some servers used to set it to zero or 1 a long time ago (hope none do it know but don't remember - we could also log an error in dmesg on maxmpxcount set to implausible value of 0, 1 or 2). I am not too worried about multiple oplocks in flight as long as we have one in reserve for oplock and one in reserve for echo. -- 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
