Date: Sat, 15 Sep 2001 16:30:00 +0100 From: ian j hart <ianjhart@ntlworld.com> To: "ports@FreeBSD.ORG" <ports@FreeBSD.ORG> Cc: "Stephen D. Spencer" <bsd-stable@boneyard.lawrence.ks.us>, "dwcjr@FreeBSD.org" <dwcjr@FreeBSD.ORG> Subject: Re: kernel oplocks Message-ID: <3BA373F8.5FE5D35F@ntlworld.com> References: <Pine.BSF.4.10.10109140715160.5380-100000@madeline.boneyard.lawrence.ks.us> <3BA3616C.31F9E9D0@ntlworld.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(from stable) > "Stephen D. Spencer" wrote: [snip kernel oplocks - separate post] > > From my research, it appears that oplocks are a performance > > feature that alots file/record(?) locking capabilities to the > > client for as long as that client is the only system > > accessing the file in question. (does away with the latency > > of going over the network to do file/record(?) locking. I'm > > not an expert on this subject, so I would send you elsewhere > > for a definitive description on what oplocks are. > > The Using Samba O'Reilley book is included with the samba docs > > and includes a description and some diagrams involving > > how oplocks work and what they are for) That was my conclusion also. > > > > If someone else comes along and accesses the file, the server > > is supposed to force the client to give up its oplock and go > > back to the server for locking operations. At any rate, > > there have been a number of commits to oplock.c since the > > release of 2.2.1a in July. I'm waiting for these updates > > to either settle or for 2.2.2 to come out before re-enabling > > oplocks. In the mean time, our file server being the big, > > beefy box that it is, is having no difficulty keeping up with > > the load sans oplocks. > > > > Stephen Spencer | > > | "Mutton yesterday, mutton today, and blimey, > > | if it don't look like mutton again tomarrer" > > | -Bert > NB: The following is my opinion from a very brief look at the code. Use a sizable pinch of salt. 'A' has oplock 'B' wants oplock The code is rather complex, as I expected, but it looks like the 'B' client sends the 'A' client a break oplock message, and then waits. This is the source of the "no response received to oplock break request..." messages. This is going to cause problems with more that a few simultainious clients. That's why there is a contension limit. This is set to 2 by default. In other words if there are more than two competing clients, turn off oplocks for that file. I was seeing lots of these no responce messages, and the loading went off the scale. Maybe this code is broken or has some kind of race. I'm also not sure that there are not problems with the underlying non-oplock locks. This is a read only share I wouldn't expect any blocking at that level. I've downloaded the 2.2 code and I'll have a look during the weekend. -- ian j hart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA373F8.5FE5D35F>