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 : c.m.e.reniers@philips.com -------------- next part -------------- HTML attachment scrubbed and removed
Eddy, As you have noticed, there is currently no fix (please correct me if I'm wrong) for the oplock problems you're experiencing. the oplock errors are definitely related the performance problems your customers are complaining about. oplocks are 'opportunistic locks' in which the client machine already has the file locked and all changes are made in a cached copy of the file on the client. When oplocks work correctly, the client periodically flushes the locally cached copy of the data file back to the server. When they don't work correctly, the kind of errors that you and your customers are noticing occur. The following is an exerpt from a message posted here by Mr. Jeremy Allison, a key member of the samba development & production team: Also, something Jeremy posted to the list a few days ago: 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. At 04:34 PM 10/29/2002 +0100, c.m.e.reniers@philips.com wrote:>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 : c.m.e.reniers@philips.com
Eddy, One more thing, I have anecdotal evidence (not emperical) that we've had fewer oplock problems with our computers that are configured to use the samba server as their Domain Controller. Obviously, there is some administrative over head involved with that. If you are able to run some experiments, I'd appreciate some feedback about what worked best for you. --- Sam Barasch Computer Systems Support Department of Biostatistics University of Wisconsin Madison
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: c.m.e.reniers@philips.com [mailto:c.m.e.reniers@philips.com] Sent: 29 October 2002 15:35 To: samba@lists.samba.org 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 : c.m.e.reniers@philips.com --- 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
I've been using Samba mostly succesfully for my Linux box serving Win9x machines for a couple of years now In the last few days I've been getting all sorts of connectivity problems Most of the errors in the samba log files are like: [2003/02/06 09:54:16, 0] smbd/oplock.c:oplock_break(684) oplock_break: ERROR: oplock_break already sent for file docs/2002/200250/2500 Sow Unit/a1.dwg (dev = 1641, inode = 1131698, file_id = 211385) [2003/02/06 09:54:16, 0] smbd/open.c:open_mode_check(599) open_mode_check: FAILED when breaking oplock (3) on file /home/docs/2002/200250/2500 Sow Unit/a1.dwg, dev = 1641, inode = 1131698 This is what is in nmbd.log for the same time period: [2003/02/06 08:33:42, 0] nmbd/nmbd_incomingdgrams.c:process_get_backup_list_request(709) process_get_backup_list_request: domain list requested for workgroup JOHNSON and I am not a local master browser. [2003/02/06 09:51:00, 0] nmbd/nmbd_incomingdgrams.c:process_get_backup_list_request(709) process_get_backup_list_request: domain list requested for workgroup JOHNSON and I am not a local master browser. smbd.log isn't showing any errors I haven't touched the config files but I was playing with installing/using apt-get (on my Redhat server) and if I remember correctly it upgraded the samba package ... it is now: samba-client-2.2.7-1.7.3 samba-2.2.7-1.7.3 samba-common-2.2.7-1.7.3 I also switched the position of two autosensing 10/100 hubs on the network - but I don't think that would be the problem Any ideas?
Dear all, I am new to this, I apologise if I am using this list improperly... I'm experiencing an oplock problem since installing windows 2000 service pack 4. The problem was not solved by upgrading from Samba 2.2.3a to 3.0.0 rc4 When I open an excel file from the windows environment no oplock is activated. This causes the problem that when I save the file I get a standard "do you want to overwrite" dialogue. Once the file's been saved once, the oplock kicks in "EXCLUSIVE+BATCH" and all is fine. (MS Word doesn't have the problem). I don't understand how oplock works, and why it's not locking the file to me as a user when I open it, but only when I save it. Can someone let me know where I might learn about oplocks or explain what the problem is so I might solve it? I've got 500 points (maybe more if it's complicated) running on this on experts exchange if anyone wants to answer it there: http://www.experts-exchange.com/Networking/Linux_Networking/Q_20749863.h tml Do I need to subscribe to the list to get an answer? Many thanks in advance, Charlie Leach