[Alan Emery <ademery@xxxxxxxxxx>]

The opportunistic lock (oplock) function allows an application to open a file that might be used by multiple applications, as though it was the only application using the file if the application makes the first open request. For example, there may be a log file that could be written to by multiple applications, but normally only one application actively uses (either reads or writes) the log file. The application that actively uses the log could open it via oplock as though it was the exclusive user of the log file, without having to lock file range bytes as it added to the log file. It also means the changes to the open file can be made on the client (application) side of the connection and be written in bulk at a later time, a potential performance improvement.

When a second application requests access to a file with an outstanding oplock, the initial application having the existing oplock is notified by the server as seen below in your trace record 1. The prior application, if acting politely, will then flush it's buffers and write any file changes to the server. After writing the changes the first application typically issues a lock for only the range of bytes it needs to use, releasing the overall lock of the file. From the snippet below, it looks like the original application is not releasing it's lock on the file.

Trace the FID (file handle) in the packets below back through earlier trace records to identify an OpenX, Open, Create or MakeNew SMB request which should then identify the file that is being opportunisticly locked. That may provide you some additional hints about which application is issuing the original oplock and why it might delay releasing an oplock. If the previous Open etc. command is not in the trace, you may have to take a longer trace in order to identify the original oplock request.

The symptom of a client hanging up would be consistent with an oplock not being released by the first file user when the hanging client is asking for access to the same file.

Alan Emery

IBM Global Solution Center

Prize Jose <PJose@xxxxxxx>

Prize Jose <PJose@xxxxxxx>
Sent by: ethereal-users-bounces@xxxxxxxxxxxx

03/02/2005 10:38 AM

Please respond to
Ethereal user support

To	ethereal-users@xxxxxxxxxxxx
cc
Subject	[Ethereal-users] OPLOCK

Hello all,

I captured a trace using ethereal during a performance problem.

I see two LOCK requests just before the client PC seems hanging.

Here is the details of the lock  from SMB details

Server is Novel and client is Windows XP.

Please note the lock types( 0x02 and 0x12) in both these requests.

Can some one please explain the meaning of these lock requests.

I don't see any  entries for either client or server for the next few
minutes.

1. From  Server ------->  client

Locking AndX Request :(0x24)
Word Count (WCT) : 8
AndXCommand: No further commands (0xff)
Reserved: 00
AndXoffset: 57054
FID : 0x4014

Lock Type: 0x02
Oplock level :  Level 2 oplock currently held by client (1)
Timeout :  Return immediately (0)
Number of Unlocks : 0
Number of Locks : 0


2. From  Client -----> Server

Locking AndX Request :(0x24)
Word Count (WCT) : 8
AndXCommand: No further commands (0xff)
Reserved: 00
AndXoffset: 57054
FID : 0x4014

Lock Type: 0x12
Oplock level :  Level 2 oplock currently held by client (1)
Timeout :  wait indefinitely   (-1)
Number of Unlocks : 0
Number of Locks : 0


Thanks

Prize Jose





_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users