Environment
Novell Client 4.70 for Windows NT
Novell Client 4.71 for Windows NT
Novell Client 4.80 for Windows NT/2000
Novell Client 4.81 for Windows NT/2000
Novell Client 4.82 for Windows XP
Novell Client 4.83 for Windows NT/2000/XP
Novell Client 4.9 for Windows NT/2000/XP
Novell Client 3.20 for Windows 95/98
Novell Client 3.21 for Windows 95/98
Novell Client 3.30 for Windows 95/98
Novell Client 3.31 for Windows 95/98
Novell Client 3.32 for Windows 95/98
Novell Client 3.4 for Windows 95/98
Novell NetWare 5.0
Novell NetWare 5.1
Novell NetWare 6.0
Novell NetWare 6.5
Novell Client 4.71 for Windows NT
Novell Client 4.80 for Windows NT/2000
Novell Client 4.81 for Windows NT/2000
Novell Client 4.82 for Windows XP
Novell Client 4.83 for Windows NT/2000/XP
Novell Client 4.9 for Windows NT/2000/XP
Novell Client 3.20 for Windows 95/98
Novell Client 3.21 for Windows 95/98
Novell Client 3.30 for Windows 95/98
Novell Client 3.31 for Windows 95/98
Novell Client 3.32 for Windows 95/98
Novell Client 3.4 for Windows 95/98
Novell NetWare 5.0
Novell NetWare 5.1
Novell NetWare 6.0
Novell NetWare 6.5
Situation
File Caching and Opportunistic Locking
Resolution
Description:
There has been much confusion regarding File Caching and
Opportunistic locking in NetWare environments. The purpose of
this document is to explain how opportunistic locking is
implemented.
It is much faster to read and write data from memory than it is from disk. It is also much faster to read and write data from the local hard drive of a workstation than it is from the network server. For this reason Opportunistic locking or op-locking was invented.
There are currently 2 different levels of op-locking included in both the Novell client and server software.
Op-locking level 2 allows the first
workstation needing write access to a network file, to copy the
entire file down to it's local memory to perform file operations.
As long as no other user needs to modify the file, then all
operations will be performed quickly using only workstation
resources. No further packets are sent back and forth between the
workstation and server. Other workstations can still access the
file without effecting the workstation that holds the op-lock as
long as their access is restricted to read access only. Once the
workstation has completed it's need for the file, then the data is
flushed back out to the server. The server then commits the new
data to disk.
Op-locking can be a great performance
boost. But this is not always the case. Everything is dependent on
the network environment. With applications where many users are
modifying the same files, op-locking gives you no real advantages.
If anything, it adds to overhead and may decrease performance. On
the other hand in applications or situations where not more then
one user is modifying a file, file access and performance can be
greatly increased. This allows the workstation to utilize
op-locking and gain a considerable amount of performance
gain.
Implementation:
The Novell client implements op-locking
through a new NCP (87,32). Originally, when the Novell client
needed to open a file it would issue an NCP 87,01 (Open/Create file
or subdirectory) request. Novell enhanced the 87,01 NCP request
structure to include a flag (OCCRetFlag) to indicate to the server
the desire for an op-lock. The new NCP 87,32 (Open/Create file
or subdirectory with Callback) reflects this enchancement to the
87,01 request. It utilizes the same structure as NCP 87,01 with the
exception of this new flag. When clients are configured to
support op-locking/File Caching then open requests are performed
with the enhanced 87,32 NCP.
History:
Novell experienced a
number of issues regarding op-locking after the initial release of
the Novell client for Windows 95. For this reason the feature was
disabled by default. In the Win9x versions of the client you could
turn on op-locking by changing the value in the advanced settings
of the client. The NT client was hard coded to be disabled so it
didn't matter what you set the value to in the advanced settings
tab. Starting with the Novell client versions 3.2 and 4.7 Novell
re-enabled op-locking as the default. In the NT client we also
changed the name of the setting to "File Caching"
Logic Flow:
The way that op-locking works is as
follows... (this scenario is the same with level 1 or level 2
locks)
1. The first workstation attempting to
access a file will issue an NCP 87,32 (Open/Create File or
Subdirectory with Callback).
2. The server looks at the file and if no
other users have access to the file then the server will respond to
the workstation with the file handle and a flag indicating that the
workstation can have the lock. (a level 1 lock)
3. The workstation then copies the entire
file down to the local workstation memory to work on the
file.
4. Once the workstation has completed it's
work on the file it will then flush it's memory back to the
server.
5. The server will then commit the new file
back to disk.
6. The workstation sends a request to the
server via NCP 87,34 to clear it's level 1 lock.
7. The workstation finally requests to close
the file.
Now lets say that two workstations are
attempting to access the same file. (this scenario applies to
level 1 locks only)
1. The first workstation attempting to
access a file will issue an NCP 87,32 (Open/Create File or
Subdirectory with Callback).
2. The server looks at the file and if no
other users have access to the file then the server will respond to
the workstation with the file handle and a flag indicating that the
workstation can have the lock.
3. The workstation then copies the entire
file down to the local workstation memory to work on the
file.
4. The second workstation attempting to
access the same file will issue an NCP 87,32 (Open/Create File or
Subdirectory with Callback).
5. The server looks at the file and
determines that the first workstation has an op-lock on the
file.
6. The server does not respond to the second
workstation.
7. Instead the server sends a directed
broadcast to the first workstation notifying it to clear it's
op-lock.
8. The first workstation sends an
acknowledgment (NCP 87,34) back to the server indicating that it
had received the lock release request and is starting to flush the
data back to the server.
9. The first workstation writes the data
back to the server.
10. Once the workstation has completely
flushed any changes to the file back to the server it issues a Open
Callback control (NCP 87,34) to clear the op-lock.
11. The server commits the changes back to
disk.
12. At this point the server will respond
back to the second workstation with a file handle and a flag set to
indicate that the workstation cannot have a level 1 lock.
13. Now both workstations have access to the
file but neither have a level 1 lock.
Now lets say that two workstations are
attempting to access the same file, One with READ/WRITE access and
the other with READ ONLY access. (this scenario applies
to level 2 locks only) Level 2 locks are basically an
extension of the level 1 locking process. This adds additional
logic when multiple users attempt to access the same file resource.
In all cases, the client initially attempts to acquire a level 1
lock. If the level 1 lock fails, then it attempts to acquire a
level 2 lock.
1. The first workstation attempting to
access a file will issue an NCP 87,32 (Open/Create File or
Subdirectory with Callback). This is the request to acquire a level
1 lock.
2. The server looks at the file and if no
other users have access to the file then the server will
respond to the workstation with the file handle and a flag
indicating that the workstation can have the level 1
lock.
3. The workstation then copies the entire
file down to the local workstation memory to work on the
file.
4. The second workstation attempting
to open the same file with
READ ONLY access will issue an NCP 87,32
(Open/Create File or Subdirectory with Callback).
5. The server looks at
the file and determines that the first workstation has a level 1
op-lock on the file.
6. The server does not
respond to the second workstation.
7. Instead the server
sends a directed broadcast to the first workstation notifying it to
clear it's op-lock.
8. The first workstation
sends an acknowledgment (NCP 87,34) back to the server indicating
that it had received the lock release request. At this point the
level 2 locking logic activates.
9. The workstation now, instead of
flushing it's data back to the server makes an additional request
to the server. This request is performed on the same NCP 87,34
request packet but contains an additional flag to request that the
server change the level 1 lock to a level 2 lock.
10. The server analyzes the second
workstations request to open the file to determine what rights were
requested. Since in this example the request was for READ ONLY
access, the server responds back to the first workstation that a
level 2 lock has been granted.
11. The server now responds back to the
second workstation with a file handle and a flag to indicate that
no level 1 oplock has been granted.
12. Both workstations now have access
to the same file. The first workstation continues to work out of
memory and maintains it's level 2 lock. The second workstation has
READ ONLY access and reads the contents of the file as
represented by the server file system.
(Note that packet traces will show that the
second workstation will make additional requests to acquire a level
2 lock since the server had replied that a level 1 lock could not
be granted. These requests for a level 2 lock will
fail since the first workstation has already obtained the
level 2 lock. If the second workstation subsequently requests that
the server grant WRITE access to the file, then the same process of
clearing the lock, as with oplock level 1, will be
observed.)
Now lets say that 2 workstations are
attempting to gain WRITE access to the same file. (this
scenario applies to level 2 locks only)
1. The first workstation attempting to
access a file will issue an NCP 87,32 (Open/Create File or
Subdirectory with Callback).
2. The server looks at the file and if no
other users have access to the file then the server will
respond to the workstation with the file handle and a flag
indicating that the workstation can have the level 1 lock.
3. The workstation then copies the entire
file down to the local workstation memory to work on the
file.
4. The second workstation now attempts to
access the same file with WRITE access and issues an NCP 87,32
(Open/Create File or Subdirectory with Callback) request.
5. The server looks at the file request and
determines that the first workstation has a level 1 op-lock on
the file.
6. The server does not respond to the second
workstation.
7. Instead the server sends a directed
broadcast to the first workstation notifying it to clear it's
lock.
8. The first workstation sends an
acknowledgment (NCP 87,34) back to the server indicating that it
had received the lock release request.
9. The first workstation now requests
to change the level 1 lock to a level 2 lock.
10. The server analyzes the second
workstation's request and determines that WRITE access was
requested. Because more then one resource needs WRITE access to the
same file, then neither can have a level 1 or level 2 lock.
11. The server responds back to the request
to change from level 1 to level 2 with a negative response. The
first workstation needs to clear it's level 1 lock so that the
server can grant the second workstation WRITE access to the same
file.
12. The first workstation acknowledges the
level 2 lock failure and then starts flushing the changed file
information back to the server.
13. The server commits the changes back to
disk.
14. The first workstation requests to
clear it's level 1 lock.
15. At this point the server will respond
back to the second workstation with a file handle and a flag set to
indicate that the workstation cannot have a lock.
16. Now both workstations have write access
to the file but neither have a lock.
Novell Client
Settings:
To disable op-locking in the client, do
perform the following:
1. On Windows 9x workstations go to the"Advanced Settings" tab on the "Novell Client Properties..." and
turn off the setting for op-locking.
2. On Windows NT/2000/XP workstations go to
the "Advanced Settings" tab on the "Novell Client Properties..."
and turn off the setting for File Caching.
If the Novell client has this setting turned
off then it will issue 87,01 requests to open files instead of the
new 87,32.
Server Settings:
With NetWare 5 SP5 or greater, a server
side setting allows network administrators the ability to turn
off op-locking via the server console.
"set client file caching enabled =
on/off"
(Monitor.nlm: Server Parameters/NCP/Client
File Caching Enabled)
When the server settings is disabled, then
with Novell clients older then 4.9, the client will still issue the
same NCP 87,32 request, but each time the server responds
with the op-lock flag set to indicate that the workstation
cannot have a lock on the file. Starting with version 4.9 of the
Novell client for Windows NT/2000/XP the client reads the server
settings upon initial connection and then sends the appropriate
request (87,01 or 87,32) depending on the value of the server set
parameters. Note that on NetWare servers there is an additional
setting to enable/disable op-lock level 2 support.
"set level 2 oplocks enabled =
on/off"
(Monitor.nlm: Server Parameters/NCP/Level 2
Oplocks Enabled)
It is possible to disable level 2 locks and
still allow level 1 locks to utilized by turing off level 2 support
at the server. But, it is not possible to allow level 2 locks
if level 1 locks have been disabled.
Troubleshooting:
Many times Novell Technical Support (NTS)
will ask customers to turn off op-locking during the process of
troubleshooting problems. Depending on your environment this may
impact user performance. In the case of many users
modifying/sharing the same files then a performance decrease may
occur. But in the case of users activity being limited to single
file access, then performance may increase.
It is not a good practice to turn off
op-locking in an attempt to work around an op-locking issue. If an
issue is found that appears to be an op-locking failure, then
appropriate troubleshooting steps should be taken so that the
proper information can be reported to Novell engineering for
resolution. Many times customers are told to turn off op-locking
when they encounter problems. It is in Novell's and the customers
best interest to identify and resolve any issues relating to the
op-locking code in either the server or client. This feature can
greatly enhance performance if working correctly.
It is recommend that the latest versions of
the Novell client are utilized. There have been a number of issues
resolved within each version related to op-locking. Also, if
running NetWare 4.x you must have the patch file occopnfx.nlm
running. On NetWare 5.x and 6x we strongly recommend you have the
latest service pack for your OS.
Additional Information
Formerly known as TID# 10071902