Date: Sat, 15 Sep 2001 15:10:52 +0100 From: ian j hart <ianjhart@ntlworld.com> To: "Stephen D. Spencer" <bsd-stable@boneyard.lawrence.ks.us> Cc: "stable@FreeBSD.ORG" <stable@FreeBSD.ORG> Subject: Re: kernel oplocks Message-ID: <3BA3616C.31F9E9D0@ntlworld.com> References: <Pine.BSF.4.10.10109140715160.5380-100000@madeline.boneyard.lawrence.ks.us>
next in thread | previous in thread | raw e-mail | index | archive | help
"Stephen D. Spencer" wrote: > > On Wed, 12 Sep 2001, ian j hart wrote: > > > Date: Wed, 12 Sep 2001 23:59:34 +0100 > > From: ian j hart <ianjhart@ntlworld.com> > > To: "stable@FreeBSD.ORG" <stable@FreeBSD.ORG> > > Subject: kernel oplocks > > > > Samba now comes configured with kernel oplocks enabled by > > default, implying this is part of the kernel. Can someone > > confirm the status of this. ie is it established, or is it > > a new feature. I wouldn't mind knowing where the source is. > > A quick search revealed nothing. > > > > I just went through this over the last couple weeks. > > Currently, the only systems that currently support kernel > oplocks are IRIX and Linux 2.4.x. Without kernel oplocks, > samba has support for generic user-land oplock support. > This support is broken... something about spinning fcntl > locks if I remember correctly. At any rate, explicitly > turning oplocks off will do away with the error messages > and (if you haven't seen them yet) the eventual freezing > up of your smbd process. Either the docs or the value in smb.conf.default is wrong. This is what had me confused. From the (html) docs. <quote> kernel oplocks (G) For UNIXes that support kernel based oplocks (currently only IRIX and the Linux 2.4 kernel), this parameter allows the use of them to be turned on or off. Kernel oplocks support allows Samba oplocks to be broken whenever a local UNIX process or NFS operation accesses a file that smbd(8) has oplocked. This allows complete data consistency between SMB/CIFS, NFS and local file access (and is a very cool feature :-). => This parameter defaults to on on systems that have the support, and off on systems that don't. You should never need to touch this parameter. See also the oplocks and level2 oplocks parameters. =>? Default: kernel oplocks = yes </quote> Defaults to yes, but we don't have this feature (yet). The rest of this belongs on ports. EOT. Thanks. > > 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) > > 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 -- ian j hart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA3616C.31F9E9D0>