A full explanation of oplocks from Jeremy below. The basic rule seems to be if a file is static data being shared to many people then oplocks will increase performace. If you are dishing out Office documents you had best turn oplocks off totally.
Oplocks = no Kernel Oplocks = no Level2 Oplocks = no hth Noel Ok, as promised, a brief explaination of oplocks, share modes and locking. When a client opens a file it can request an "oplock" or file lease. This is (to simplify a bit) a guarentee that no one else has the file open simultaneously. It allows the client to not send any updates on the file to the server, thus reducing a network file access to local access (once the file is in client cache). An "oplock break" is when the server sends a request to the client to flush all its changes back to the server, so the file is in a consistent state for other opens to succeed. If a client fails to respond to this asynchronous request then the file can be corrupted. Hence the "turn off oplocks" answer if people are having multi-user file access problems. Unless the kernel is "oplock aware" (SGI IRIX and Linux are the only two UNIXes that are at the moment) then if a local UNIX process accesses the file simultaneously then Samba has no way of telling this is occuring, so the guarentee to the client is broken. This can corrupt the file. Short answer - it you have UNIX clients accessing the same file as smbd locally or via NFS and you're not running Linux or IRIX then turn off oplocks for that file or share. "Share modes". These are modes of opening a file, that guarentee an invarient - such as DENY_WRITE - which means that if any other opens are requested with write access after this current open has succeeded then they should be denied with a "sharing violation" error message. Samba handles these internally inside smbd. UNIX clients accessing the same file ignore these invarients. Just proving that if you need simultaneous file access from a Windows and UNIX client you *must* have an application that is written to lock records correctly on both sides. Few applications are written like this, and even fewer are cross platform (UNIX and Windows) so in practice this isn't much of a problem. "Locking". This really means "byte range locking" - such as lock 10 bytes at file offset 24 for write access. This is the area in which well written UNIX and Windows apps will cooperate. Windows locks (at least from NT or above) are 64-bit unsigned offsets. UNIX locks are either 31 bit or 63 bit and are signed (the top bit is used for the sign). Samba handles these by first ensuring that all the Windows locks don't conflict (ie. if other Windows clients have competing locks then just reject immediately) - this allows us to support 64-bit Windows locks on 32-bit filesystems. Secondly any locks that are valid are then mapped onto UNIX fcntl byte range locks. These are the locks that will be seen by UNIX processes. If there is a conflict here the lock is rejected. Note that if a client has an oplock then it "knows" that no other client can have the file open so usually doesn't bother to send to lock request to the server - this means once again if you need to share files between UNIX and Windows processes either use IRIX or Linux, or turn off oplocks for these files/shares. Hope this is clear :-). Jeremy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:c.m.e.reniers@;philips.com] Sent: 29 October 2002 15:35 To: [EMAIL PROTECTED] Subject: [Samba] oplock problems We are running samba 2.2.3a ( for about 3000 users ) on HP/UX 11.11 fileservers. Our customers are complaining about slow response on the opening/closing of files in office/excel etc. In the samba log file we see the following messages : [2002/10/29 09:03:27, 0] ../source/smbd/oplock.c:(761) oplock_break: receive_smb timed out after 30 seconds. oplock_break failed for file My Documents/servers.doc (dev = 40220001, inode = 229991, file_id = 240). [2002/10/29 09:03:27, 0] ../source/smbd/oplock.c:(833) oplock_break: client failure in oplock break in file My Documents/servers.doc [2002/10/29 09:03:27, 0] ../source/smbd/reply.c:(4387) reply_lockingX: Error : oplock break from client for fnum = 14026 and no oploc k granted on this file (My Documents/servers.doc). We found out that these messages correspond with the slow response that our users are seeing. I've searched the samba archive and there are more people having these messages. The solutions I found were : - You may have a netwerk problem ( which is NOT the case in our situation ) - Turn oplocks off ( But this may introduce a performance problem ) Can somebody please explain : - What this message really means. - Can it be related to the slow response that our customers are complaining about - Is there a solution to this probem ( our network is ok, turning oplocks off is not a solution .. ) Regards, Eddy Reniers, Philips Research Laboratories Department Computer Services, Building WY p 29- postbox WY01 Prof.Holstlaan 4, 5656 AA Eindhoven, The Netherlands Phone : +31-40-27-44703 Email : [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
