So, Martyn would it be true to say this: Oplocks should only really be used in situations where a server is sharing program files or other relatively static data ? Home drives and other files which are primarily only opened by one user at a time would see no value in oplocks ? Databases and other dynamic data shares which can be altered by many users should certainly have oplocks disabled ? Thanks for your insight. Noel -----Original Message----- From: Martyn Ranyard [mailto:ranyardm@lineone.net] Sent: 06 February 2002 13:02 To: Russell Senior; jra@samba.org Cc: Samba Maillist (E-mail) Subject: Re: [Samba] Re: Samba 2.2.3 Oplock problem... I remember a talk at our lug about oplocks, If I remember correctly then the following is true : A client takes the file, caches it at client side, and oplocks it. The server then gets a different request to read the file, asks the client to send it's latest version. Here, two things can happen, 1. the client responds with changes, which the server reflects or 2. the client doesn't respond in time, in which case the server breaks the oplock and reverts the file to it's unchanged state. This is the way SMB oplocks work AFAIK Network problems can cause delays and therefore timeouts will timeout (it is their job, afterall). This is why leaky networks cause oplock problems. I contribute this hazy knowledge to the public domain, mainly to save Jeremy some time! At 08:59 AM 2/5/02 -0800, Russell Senior wrote:> >>>>> "Jeremy" == Jeremy Allison <jra@samba.org> writes: > >Jeremy> Most oplock problems are due to bad network setups (client >Jeremy> drivers, hubs etc). I haven't seen any evidence other than one >Jeremy> person having oplock problems (which is not unusual given the >Jeremy> state of many networks) that this is anything other than the >Jeremy> usual network related oplock woes. > >Can you elaborate on this? As I understand it, the oplock break >messages are getting lost, but aren't they sent over the TCP socket? >Won't the regular TCP reliability guarantees ensure it gets resent if >not ACK'd? How can network problems interfere? > > >-- >Russell Senior ``The two chiefs turned to each other. >seniorr@aracnet.com Bellison uncorked a flood of horrible > profanity, which, translated meant, `This is > extremely unusual.' '' > >-- >To unsubscribe from this list go to the following URL and read the >instructions: http://lists.samba.org/mailman/listinfo/samba=============Martyn Ranyard -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
Remember that this is from memory of a user-group meeting about 3-4 months ago, but anyway... At 04:14 PM 2/6/02 +0000, Noel Kelly wrote:>So, Martyn would it be true to say this: > >Oplocks should only really be used in situations where a server is sharing >program files or other relatively static data ?The reason M$ created oplocks was to give an overall impression of more speed. This works quite well when there is a nice tight network with no delay points or when it is likely that only one user is accessing the file at once.>Home drives and other files which are primarily only opened by one user at a >time would see no value in oplocks ?No - they would see the most value, as the file is cached at the client and any writes remain on the client until flushed back to the server, thus making write access much quicker.>Databases and other dynamic data shares which can be altered by many users >should certainly have oplocks disabled ?Whilst I cannot say one way or another on a tight network, because in theory it can slightly speed things up if say the program locks a record, and unlocks it, that kind of thing is never passed to the server if no changes are actually made. On a leaky network you are definitely right and when especially when M$ Access is used, because M$ wrote it so that it would use oplocks heavily and that just shows up the bad behavior of such predictive coding.>Thanks for your insight. >Noel > >-----Original Message----- >From: Martyn Ranyard [mailto:ranyardm@lineone.net] >Sent: 06 February 2002 13:02 >To: Russell Senior; jra@samba.org >Cc: Samba Maillist (E-mail) >Subject: Re: [Samba] Re: Samba 2.2.3 Oplock problem... > > > >I remember a talk at our lug about oplocks, If I remember correctly then >the following is true : > >A client takes the file, caches it at client side, and oplocks it. >The server then gets a different request to read the file, asks the client >to send it's latest version. >Here, two things can happen, 1. the client responds with changes, which the >server reflects or 2. the client doesn't respond in time, in which case the >server breaks the oplock and reverts the file to it's unchanged >state. This is the way SMB oplocks work AFAIK > >Network problems can cause delays and therefore timeouts will timeout (it >is their job, afterall). This is why leaky networks cause oplock problems. > >I contribute this hazy knowledge to the public domain, mainly to save >Jeremy some time! > >At 08:59 AM 2/5/02 -0800, Russell Senior wrote: > > >>>>> "Jeremy" == Jeremy Allison <jra@samba.org> writes: > > > >Jeremy> Most oplock problems are due to bad network setups (client > >Jeremy> drivers, hubs etc). I haven't seen any evidence other than one > >Jeremy> person having oplock problems (which is not unusual given the > >Jeremy> state of many networks) that this is anything other than the > >Jeremy> usual network related oplock woes. > > > >Can you elaborate on this? As I understand it, the oplock break > >messages are getting lost, but aren't they sent over the TCP socket? > >Won't the regular TCP reliability guarantees ensure it gets resent if > >not ACK'd? How can network problems interfere? > > > > > >-- > >Russell Senior ``The two chiefs turned to each other. > >seniorr@aracnet.com Bellison uncorked a flood of horrible > > profanity, which, translated meant, `This is > > extremely unusual.' '' > > > >-- > >To unsubscribe from this list go to the following URL and read the > >instructions: http://lists.samba.org/mailman/listinfo/samba > >=============>Martyn Ranyard > > >-- >To unsubscribe from this list go to the following URL and read the >instructions: http://lists.samba.org/mailman/listinfo/samba > >-- >To unsubscribe from this list go to the following URL and read the >instructions: http://lists.samba.org/mailman/listinfo/sambaMartyn Life's a bitch, but so am I.
Home drives or files that are opened by only one user at a time would see the greatest benefit of oplocks. In this case, oplock can dramatically improve both read and write performance with caching on the client. On Wed, 6 Feb 2002, Noel Kelly wrote: So, Martyn would it be true to say this: Oplocks should only really be used in situations where a server is sharing program files or other relatively static data ? Home drives and other files which are primarily only opened by one user at a time would see no value in oplocks ? Databases and other dynamic data shares which can be altered by many users should certainly have oplocks disabled ? Thanks for your insight. Noel -----Original Message----- From: Martyn Ranyard [mailto:ranyardm@lineone.net] Sent: 06 February 2002 13:02 To: Russell Senior; jra@samba.org Cc: Samba Maillist (E-mail) Subject: Re: [Samba] Re: Samba 2.2.3 Oplock problem... I remember a talk at our lug about oplocks, If I remember correctly then the following is true : A client takes the file, caches it at client side, and oplocks it. The server then gets a different request to read the file, asks the client to send it's latest version. Here, two things can happen, 1. the client responds with changes, which the server reflects or 2. the client doesn't respond in time, in which case the server breaks the oplock and reverts the file to it's unchanged state. This is the way SMB oplocks work AFAIK Network problems can cause delays and therefore timeouts will timeout (it is their job, afterall). This is why leaky networks cause oplock problems. I contribute this hazy knowledge to the public domain, mainly to save Jeremy some time! At 08:59 AM 2/5/02 -0800, Russell Senior wrote:> >>>>> "Jeremy" == Jeremy Allison <jra@samba.org> writes: > >Jeremy> Most oplock problems are due to bad network setups (client >Jeremy> drivers, hubs etc). I haven't seen any evidence other than one >Jeremy> person having oplock problems (which is not unusual given the >Jeremy> state of many networks) that this is anything other than the >Jeremy> usual network related oplock woes. > >Can you elaborate on this? As I understand it, the oplock break >messages are getting lost, but aren't they sent over the TCP socket? >Won't the regular TCP reliability guarantees ensure it gets resent if >not ACK'd? How can network problems interfere? > > >-- >Russell Senior ``The two chiefs turned to each other. >seniorr@aracnet.com Bellison uncorked a flood of horrible > profanity, which, translated meant, `This is > extremely unusual.' '' > >-- >To unsubscribe from this list go to the following URL and read the >instructions: http://lists.samba.org/mailman/listinfo/samba=============Martyn Ranyard