The information in this document is subject to change without notice.
Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but
not limited to, the implied warranties of merchantability and fitness for a particular purpose.
Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the furnishing, performance,
or use of this material.
Warranty. A copy of the specific warranty terms applicable to your Hewlett-Packard product
and replacement parts can be obtained from your local Sales and Service Office.
Restricted Rights Legend. Use, duplication or disclosure by the U.S. Government is
subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and
subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights
clause at FAR 52.227-19 for other agencies.
Hewlett-Packard Company
19420 Homestead Road
Cupertino, California 95014 U.S.A.
Use of this manual and flexible disk(s) or tape cartridge(s) supplied for this pack is restricted
to this product only. Additional copies of the programs may be made for security and back-up
purposes only. Resale of the programs in their present form or with alterations, is expressly
prohibited.
B.5 Competitor’s Claims for NFS Non-Locking Protection ..........................................48
3
Chapter 1 Introduction
A key feature of HP’s CIFS/9000 product is file server consolidation on a UNIX
platform with transparent shared file access between Windows and UNIX clients. A major
challenge of shared file access is providing secure, fast access for Windows, UNIX, and mixed
client environments. File access security is implemented using file locking schemes
typically executed at the file system level and/or application level, but while Windows
provides a comprehensive locking model, UNIX and NFS only provide an advisory locking
model. The significant differences of the platform locking models results in integration
opportunities and issues for CIFS/9000, and these must be clearly identified and addressed
for CIFS/9000 potential installations.
4
Chapter 2 CIFS/9000 Product Overview
CIFS is a file system specification called Common Internet File System, which evolved from
Microsoft’s SMB protocol for Windows operating systems. CIFS/9000 is an HP-UX product
(based upon Samba version 2.0.6, 2.0.7 in 3/2001, or 2.0.9 in 9/2001) that utilizes the
Common Internet File System to provide two major benefits for two platforms. First, the
CIFS/9000 Server delivers smooth file and print sharing access to both Windows and UNIX
platform clients, but with all of the benefits of a HP-UX operating system. Second, the
CIFS/9000 Client delivers HP-UX client access to both Windows and UNIX file servers, and
integrated user authentication between HP-UX and Windows domains using NTLM.
CIFS/9000 allows management consolidation of many Windows servers onto a reliable,
highly available HP-UX operating system, while still delivering file access to Windows
clients utilizing their native CIFS (SMB) protocol. CIFS/9000 also provides a common
platform for efficient file sharing from varying client access methods: Windows, UNIX, NFS,
or PC/NFS. The versatility of CIFS/9000 allows Windows-only file serving, UNIX-only file
serving, or mixed file serving.
To ensure integrity and security of user data files despite the variable client access methods,
file locking can be enabled at the file system and/or application level.
5
Chapter 3 File Locking Overview
File locking is typically initiated by the file system – either by configuration parameters or
API and function calls – to prevent data corruption by more than one process accessing a file
while it is open in write mode (either dual writes occurring, or reading a file that has since
been changed due to a write – “stale data”). There are two important factors to consider
when enabling file locking: first – when to use file locking; second – how to lock the file.
File locking provides a security and/or integrity benefit, but the benefit is not free. Locking
uses system resources, therefore it can affect performance. In addition, some kinds of locking
can actually enhance performance, but expose data to corruption under certain types of
access. Also, using file-system -provided file locking can be redundant if data is already
locked or managed at the application level, thus using system resources affecting
performance for no benefit. Finally, how data is used should partially dictate how files are
locked: if a file is to be opened read-only, then locking the file may not make much sense.
HP Sales Force personnel often encounter RFPs that include CIFS/NFS cross-platform file
locking as a requirement. It is essential that the TC or SR understand what security and
data integrity issues are driving the file locking requirement. Customers often include such
requirements without understanding their own environment.
HP-UX 11 CIFS/9000 / NFS File Server & Storage
Files Accessed by
Windows Clients
Shared CIFS/NFS
File Access
Files Accessed by
NFS Clients
Locking Needed?Data MgtACLrwxFilename
No data managementNo ACLRead onlyFilename1
No data managementACE on ACLRead/WriteFilename2
PDM, Clearcase, etc…No ACLRead/WriteFilename3
No data managementNo ACLRead/WriteFilename4
YES – Locking Needed
NO
NO
NO
1. Are there files or directories that will be accessed by both CIFS and NFS?
2. How many files or directories, and what kind of data?
3. Will clients have write access to the files or directories?
4. Are there ACLs on the file or directories that manage client access?
5. Is there a data management application that administers access (Clearcase or PDM server)?
6
Educating customers about when file locking is required will reduce the
possibility of this feature being a lockout for bidding a deal2.
How a file is locked by a file system depends upon the locking features that are invoked
(Windows has multiple locking modes), or what platform the file resides upon (Windows or
UNIX), or what access method the client is using to open the file. With CIFS/9000 providing
file-sharing access to multiple client types, the shared (heterogeneous) access combinations
can become confusing. We will start to clarify locking behavior in these combinations by
explaining how each access method locks a file on its own file system (homogenous).
2
See Appendix B
7
Chapter 4 File Locking Implementations
File systems and pseudo file systems (like PC-NFS) implement autonomous file locking
models. These file-locking models are invoked by the particular file system, and do not
necessarily interoperate, or even know each other exist. Thus, when multiple client access
methods open the same file – even with valid locking procedures for the opening file system –
the locks can be ignored, resulting in concurrent file access and likely data corruption. To
understand how the different file locking mechanisms interoperate (or do not interoperate),
we must first understand how file locking is implemented for homogeneous access on the
following file systems:
Windows (CIFS),
UNIX (JFS, HFS, etc)
NFS,
PC-NFS.
4.1 WINDOWS (CIFS)
The Windows file system (using CIFS) utilizes three different file-locking mechanisms:
MANDATORY LOCKING is invoked at file open by the Windows Createfile API. Locking
parameters supplied to Createfile include access mode and share mode.
Access mode defines how an application (caller of Createfile) wants to access the file:
Read: Read access only
Write: Write access only
Read-Write: Read and Write access
Share mode defines how an application wants to limit or grant concurrent access while it
has the file open, essentially comprising the locking scenario for MANDATORY LOCKS:
Deny-None: Concurrent read and write access allowed
Deny-All: No concurrent read or write access allowed
Deny-Read: No concurrent read access allowed
Deny-Write: No concurrent write access allowed
These are Windows default file locking mechanisms. There are obscure ways to disable
mandatory locks, but they should never be disabled (which is why they are obscure).
Windows documentation uses the terms “mandatory” and “share mode”. However, it is
helpful to think of mandatory share mode locking as “OPEN MODE LOCKING”, because it is
initiated during a file open, so subsequent references will use “Mandatory Share Mode (Open
Mode) Locking”.
8
BYTE RANGE LOCKING is invoked programmatically – on a file that is already open - by
the Windows LockFile and LockFileEx APIs when a client application wants to lock a region
of a file for exclusive access.
LockFile parameters only specify the file name and byte ranges to be locked. Therefore the
lock must be exclusive – all other processes are denied access to the specified region of the
file. If the region cannot be locked, the API returns immediately – it does not block or wait.
LockFileEx includes a flags parameter that allows the process to wait for a locked region of a
file to unlock. It also includes a sharing option that allows another process to read the locked
region concurrently but denying write access concurrently.
Byte Range locks are honored unilaterally by Windows and Windows applications that call
LockFile and LockFileEx, so a process is guaranteed to have the particular access granted by
the API when the call succeeds.
OPPORTUNISTIC LOCKING (Oplocks) is invoked by the Windows file system (as opposed
to an API) via registry entries (on the server AND client) for the purpose of enhancing
network performance when accessing a file residing on a server. Performance is enhanced by
caching the file locally on the client which allows:
Read-ahead: The client reads the local copy of the file, eliminating network latency
Write caching: The client writes to the local copy of the file, eliminating network
latency
Lock caching: The client caches application locks locally, eliminating network
latency
The performance enhancement of oplocks is due to the opportunity of exclusive access to the
file, even if it is opened with deny-none, because Windows monitors the file’s status for
concurrent access from other processes.
Windows defines 4 kinds of Oplocks:
Level1 Oplock - The redirector sees that the file was opened with deny none (allowing
concurrent access), verifies that no other process is accessing the file, checks that oplocks are
enabled, then grants deny-all read-write exclusive access to the file. The client now performs
operations on the cached local file.
If a second process attempts to open the file, the open is deferred while the redirector
“breaks” the original Oplock. The Oplock break signals the caching client to write the local
file back to the server, flush the local locks, and discard read-ahead data. The break is then
complete, the deferred open is granted, and the multiple processes can enjoy concurrent file
access as dictated by mandatory or byte-range locking options. However, if the original
opening process opened the file with a share mode other than deny-none, then the second
process is granted limited or no access, despite the Oplock break.
Level2 Oplock – Performs like a level1 oplock, except caching is only operative for reads. All
other operations are performed on the server disk copy of the file.
Filter Oplock – Does not allow write or delete file access.
Batch Oplock – Manipulates file openings and closings.
9
An important detail is that Oplocks are invoked by the file system, not an application API.
Therefore, an application can close an oplocked file, but the file system does not relinquish
the Oplock. When the Oplock break is issued, the file system then simply closes the file in
preparation for the subsequent open by the second process.
4.2 UNIX
UNIX utilizes 2 kinds of file locking:
Advisory locking
Mandatory locking
Both lock types are implemented with the same function calls: fcntl and lockf. fcntl is the
POSIX interface (introduced at SVR4), and lockf is provided for backward compatibility. The
calling semantics are slightly different, but the functionality is basically the same.
Both functions specify read and/or write locking, and allow for byte-range locks or locking of
the entire file. A read lock allows concurrent access for reading, but not writing. A write
lock is exclusive.
ADVISORY LOCKING assumes that all processes attempting to access a file participate in
the locking protocol by calling the locking functions correctly and honoring the lock status of
the file. There is no requirement that a process must adhere to the advisory locking protocol.
A process that does not participate in the protocol can obliviously write or read to a file that
is locked with locking functions. Therefore there is a significant assumption of risk of data
corruption with advisory locking.
MANDATORY LOCKING is implemented with function calls identical to advisory locking.
Mandatory locking is then enabled per-file by manipulating the file’s permissions with
chmod. To enable a file for mandatory locking, the group-id bit must be set, and the execute
bit must be cleared (implying that executable files cannot be locked). Once set, any calls to
open, read, or write to a previously locked file are failed by the kernel, regardless of whether
the process participates in the file locking protocol. Most UNIX locking scenarios refer to advisory locking protocol. The UNIX mandatory option seems to be rarely utilized, so further
references to mandatory locking refer to Windows only.
Note that UNIX does not employ the concept of Mandatory Share Mode (Open Mode) locking
like Windows does. UNIX locking consists of byte range locking and is strictly programmatic
on a previously opened file. Also, UNIX is incapable of sending an oplock break to a client,
and therefore cannot interoperate with Windows clients using Opportunistic Locking.
4.3 NFS
File locking for NFS is provided by two cooperating protocols:
Network Lock Manager
Network Status Monitor
10
NETWORK LOCK MANAGER - like UNIX - uses an advisory locking protocol: an NFS
server can obliviously grant a client read and/or write access to a file that has already been
locked by another client. The NLM assumes that all processes attempting to access a file
will follow locking protocol by calling the locking functions correctly and honoring the lock
status of the file. The NLM honors read and/or write locking, and allows for byte-range locks
or locking of the entire file. A read lock allows nonexclusive concurrent access for reading,
but not writing. A write lock is exclusive. If a process is denied access due to a conflict in
lock type, it can optionally block until the lock is freed or it can return an error condition.
UNIX advisory locks are propagated to the NFS Network Lock Manager. The UNIX locking
process will interoperate with the NLM to implement the fcntl file locking calls via the NFS
mount to the actual remote disk file. Thus the file is protected from other UNIX processes
that access the file – either locally on the NFS server or via multiple NFS mounts of the
same file system – and adhere to the advisory locking protocol.
Note that UNIX/NFS does not employ the concept of Mandatory Share Mode (Open Mode)
locking like Windows does. UNIX/NFS locking consists of byte range locking and is strictly
programmatic on a previously opened file. Also, UNIX/NFS is incapable of sending an
oplock break to a client, and therefore cannot interoperate with Windows clients using
Opportunistic Locking.
NETWORK STATUS MONITOR provides the lock manager with information on host status.
It monitors the system to ensure that locks will be handled properly if a system crashes
while a file is locked. This is referred to as monitored locking. If the server crashes with
monitored locks in place, the locks will be reinstated when the server recovers. Conversely, if
the client crashes with monitored locks in place, the locks will be automatically freed by the
server and must be reinstated by the client when it recovers.
Clients have the option of using lock manager without the status monitor in which case the
locking is non-monitored. Non-monitor ed locking is provided for client systems that do not
support multi-tasking and cannot run both lock manager and status monitor at the same
time. In all other cases, monitored locking is preferred.
4.4 PC NFS
PC-NFS implements Byte Range programmatic file locking by interoperating with the server
NFS Network Lock Manager. The Windows client will propagate application byte range
locks to the UNIX server, where the NLM will interoperate with the UNIX Kernel Lock
Manager to actually place the lock on the file. PC-NFS file locking participates in the UNIX
advisory locking protocol.
PC-NFS also implements Mandatory Share Mode (Open Mode) locking between PC-NFS
clients. However, PC-NFS uses NLM to implement the share mode locks, and a Windows
client does not. Therefore, PC-NFS does not recognize Windows client Mandatory Share
Mode (Open Mode) locks, and vice versa.
Also, PC-NFS is incapable of sending an oplock break to a client, and therefore cannot
interoperate with Windows clients using Opportunistic Locking.
PC-NFS testing for this paper was done with WRQ Reflections NFS Connection Software
version 7.1.
11
Chapter 5 CIFS/9000 File Locking
Implementation
CIFS/9000 mirrors the Windows file locking mechanisms, using the CIFS (SMB) protocol to
provide Windows-equivalen t file locking on a UNIX system for Windows clients (homogenous
client access). For Windows client access to files residing on the local UNIX file system,
CIFS/9000 utilizes:
This locking scheme is executed by the CIFS/9000 smbd UNIX process. Every Windows
client connection to the CIFS/9000 server starts an individual smbd daemon that
administers the client access. The smbd daemon implements the Windows file locking
scheme, and interoperates with every other smbd daemon that is running on the local system
to coordinate the file locks that each Windows client requests. The CIFS/9000 smbd
daemons provide the common interface that ensures the validity of each file lock. However,
since the smbd is not executing on the Windows native file server, some client applications
using very strict adherence to programmatic native Windows locking protocol could exhibit
unexpected behavior.
CIFS/9000 configures file locking in the /etc/opt/samba/smb.conf file. Default values do not
need to be explicitly configured in the smb.conf file.
5.1. MANDATORY SHARE MODE LOCKING (OPEN MODE)
– as implemented by CIFS/9000 - uses Windows access modes and share modes.
Access mode:
Read: Read access only
Write: Write access only
Read-Write: Read and Write access
Share mode:
Deny-None: Concurrent read and write access allowed
Deny-All: No concurrent read or write access allowed
Deny-Read: No concurrent read access allowed
Deny-Write: No concurrent write access allowed
The Windows client application determines the access mode when calling Createfile.
CIFS/9000 disables share mode in the smb.conf file on a per -share basis:
[share_name]
share modes = no
The default is “yes”, so the parameter is usually not explicitly set unless it is set to “no”.
However, most applications expect share mode to be set to yes – don’t change it.
12
Mandatory Share Mode(Open Mode) locking applies to Windows clients only. File sharing
issues arise when concurrent file access occurs between Windows clients and UNIX clients,
PC-NFS clients, or on files that have been NFS-mounted. UNIX processes have no concept of
Mandatory Share Mode locks. A key issue with sharing files between UNIX and
Windows is that a Windows client can hold a Mandatory Share Mode lock on a file,
but a UNIX process can open the same file concurrently for write access, resulting
in unacceptable risk of data corruption. CIFS/9000 has been enhanced to translate
Windows Mandatory Share Mode locks into byte range locks, therefore providing
locking interoperation with the UNIX advisory locking protocol and reducing the
risk of data corruption.
Providing protection for Windows clients from UNIX/NFS concurrent file access is an
important added-value feature for Windows-UNIX integration, but is not a comprehensive
solution. There are Windows-UNIX integration products that can provide Windows client
Mandatory Share Mode (open mode) locking protection from UNIX/NFS processes, even if
they do not participate in the UNIX advisory locking protocol. However, if a UNIX/NFS
application is not properly coded to lock files, then there is no way to protect other
UNIX/NFS processes from concurrent file access data corruption. If data can be corrupted by
UNIX/NFS concurrent file access, then providing Windows Share Mode (open mode) locking
protection from those same UNIX/NFS processes (mixed-mode access) does not remove the
element of risk from data corruption because the locking interoperability is not
comprehensive system-wide3.
A future enhancement will protect Windows Clients with Mandatory Share Mode (open
mode) locks from UNIX/NFS concurrent file access even if the UNIX/NFS process does not
participate in the advisory locking protocol. This file locking interoperability issue is the
focus of many claims by HP’s competitors. See section 8 and Appendix B.5 for more
details.
5.2. BYTE RANGE LOCKING (programmatic) is implemented by the
Windows client calls to the LockFile and LockFileEx APIs. The smbd process honors the byte
range lock by calling the UNIX fcntl function and invoking the UNIX byte range advisory
locks on the file (see the UNIX topic above). Thus, if the Windows application sets byte range
locks, CIFS/9000 can interoperate with UNIX processes utilizing advisory locking4. Windows
client access (homogenous) will honor the CIFS/9000 byte range locks.
CIFS/9000 disables byte range locking with the “locking” parameter in the smb.conf file:
[share_name]
locking = no
The default is “yes”. If locking is set to “no”, the byte range locks will appear to succeed on
the Windows client, but the smbd will not actually apply the advisory locks to the file. When
set to yes, the second open process blocks waiting for the release of the lock. Most
applications expect the locking to be enabled (byte range locking) – don’t change it.
Strict locking changes the way byte range locking is enforced. By default, byte range locking
is implemented when a Windows client application calls the LockFile or LockFileEx APIs.
Byte range lock status is only checked when the application calls these APIs. Strict locking
enables the smbd to check for byte range locks on every read and write access to a file. The
3
See Appendix B.5
4
See Appendix B.2
13
benefit is improved security, but in most cases the additional checks will be redundant to the
application checks, and the cost will be reduced performance due to the extra overhead of
checking for locks on every read and write.
CIFS/9000 enables strict locking on a per-share basis in the smb.conf file:
[share_name]
strict locking = yes
The default is “no”.
Blocking locks enables the smbd to recognize a timeout period specified on a LockFileEx call.
If a previous lock is encountered by a client attempting a byte range lock, the smbd will wait
(block) for the timeout period to expire before failing the lock. If the previous lock is released
before the timeout, the smbd will then grant the pending lock. When disabled, the lock
request is failed immediately.
CIFS/9000 disables blocking locks on a per -share basis in the smb.conf file:
[share_name]
blocking locks = no
The default is “yes”.
5.3.OPPORTUNISTIC LOCKING (Oplocks) is implemented by the
CIFS/9000 server on a per-share basis in the smb.conf file. CIFS/9000 Oplock functionality
operates just like Windows. Oplocks are enabled by default for each share, which allows the
Windows client to cache a local copy of a file for:
Read-ahead
Write-caching
Lock caching
CIFS/9000 disables Oplocks on a per -share basis in the smb.conf file:
[share_name]
oplocks = no
The default is “yes”. The default oplock type is Level1.
CIFS/9000 enables Level2 Oplocks on a per -share basis in the smb.conf file:
[share_name]
level2 oplocks = yes
The default is “no”. Oplocks must also be set to “yes” for the Level2 oplock parameter to
function.
Oplocks apply to Windows clients only. File sharing issues arise when concurrent file access
occurs between Windows clients and UNIX clients, PC-NFS clients, or on files that have been
NFS-mounted. A key issue with sharing files between UNIX/NFS, PC-NFS, and
Windows clients is that a Windows client can request an Oplock from the
CIFS/9000 server and be granted the Oplock (thus caching the file locally), but a
14
UNIX/NFS process or PC-NFS application can open the same file for write access
without an Oplock Break being sent to the client, resulting in unacceptable risk of
data corruption. Even a UNIX/NFS process that adheres to the advisory locking protocol
will not send an oplock break. Disabling Oplocks removes the risk of this particular data
corruption, but also removes the performance benefit that Oplock file caching provides.
Currently, CIFS/9000 does not provide interoperability between UNIX/NFS, PC-NFS and
Windows clients for oplocks. However, CIFS/9000 has a planned enhancement to provide
this interoperability. This enhancement will allow CIFS/9000 to send an oplock break
to a Windows client when a UNIX/NFS process or PC-NFS application attempts to
access a file, even if the process or application does not participate in the advisory
locking protocol. This file locking interoperability issue is the focus of many claims by
HP’s competitors. See section 8 for more details.
Kernel oplocks is a Samba smb.conf parameter that notifies Samba if the UNIX kernel has
the capability to send a Windows client an Oplock Break if a UNIX process is attempting to
open the file that is cached. This parameter addresses sharing files between UNIX and
Windows with Oplocks enabled on the a Samba server: the UNIX process can open the file
that is Oplocked (cached) by the Windows client and the smbd process will not send an
Oplock break, which exposes the file to the risk of data corruption. If the UNIX kernel has
the ability to send an Oplock break, then the kernel oplocks parameter enables Samba to
send the Oplock break. Kernel oplocks are enabled on a per -server basis in the smb.conf file.
However, CIFS/9000 currently does not support kernel oplocks, so the parameter has no
effect:
[global]
kernel oplocks = yes
The default is “no”. The planned enhancement for CIFS/9000 Oplocks will likely utilize this
parameter.
Veto oplocks is a smb.conf parameter that identifies specific files for which Oplocks are
disabled. When a Windows client opens a file that has been configured for veto oplocks, the
client will not be granted the oplock, and all operations will be executed on the original file
on disk instead of a client-cached file copy. By explicitly identifying files that are shared
with UNIX processes, and disabling Oplocks for those files, the server-wide Oplock
configuration can be enabled to allow Windows clients to utilize the performance benefit of
file caching without the risk of data corruption. Veto Oplocks can be enabled on a per -share
basis, or globally for the entire server, in the smb.conf file:
Because the primary benefit of CIFS/9000 is to provide Windows client access to files
residing on a UNIX operating system, shared client access examples all include at least one
Windows client. The following examples will explain how file locking behaves when more
than one client accesses a file via a CIFS/9000 share, both locally and NFS mounted.
6.1 WINDOWS ONLY CLIENT ACCESS – Local File
System
Windows
File
The diagram above shows 2 windows clients requesting concurrent file access on the
CIFS/9000 server to a local file system. The key issue for this configuration is that
CIFS/9000 provides full Windows file locking functionality in a Windows homogenous
environment.
Mandatory Share Mode (Open Mode) locking is fully implemented.
Byte Range locking is fully implemented.
Opportunistic (Oplocks) locking is fully implemented.
UNIX
PC-NFS
CIFS/9000
Windows
NFS
16
Mandatory, Byte Range, and Opportunistic locking are all enabled by default, and should
always be enabled for a Windows-only client access environment. They may be explicitly
configured on a per-share basis by editing the smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
17
6.2 WINDOWS ONLY CLIENT ACCESS – NFS Mounted
CIFS/9000
Clients
File System
Windows
File
The diagram above shows 2 Windows clients requesting concurrent file access on the
CIFS/9000 server to a NFS mounted file system. The key issue for this configuration is that
because all Windows client access occurs via the CIFS/9000 server smbd processes, the file
access is coordinated by CIFS/9000 even thought the disk file is remote, thus providing full
file locking functionality in a Windows homogenous environment.
Mandatory Share Mode locking is fully implemented. Although no actual lock is placed upon
the disk file over the NFS mount, the client processes believe that there is, and the server
smbd processes coordinate to respect each other’s pseudo-lock. This locking scenario only
applies when a single CIFS/9000 server is supplying both client connection requests.
Byte Range locking is fully implemented. The CIFS/9000 smbd process actually calls the
UNIX fcntl to explicitly lock the byte range in UNIX with advisory byte range locks. The
UNIX byte range is then propagated to NFS, so byte range locking is interoperable with
NFS. With Windows-only concurrent access, the smbd process interprets the UNIX advisory
lock as a Windows byte range lock, which the clients honor.
.
Opportunistic (Oplocks) locking is fully implemented for the same reason as the Mandatory
Share Mode lock, and only applies when a single CIFS/9000 server is supplying both client
connection requests.
UNIX
PC-NFS
CIFS/9000
Windows
NFS
18
Mandatory, Byte Range, and Opportunistic locking are all enabled by default, and should
always be enabled for a Windows-only client access environment. They may be explicitly
configured on a per-share basis by editing the smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
These locks are valid when client access is confined to a single CIFS/9000 server that is
exclusively NFS mounting the remote file system. If another client is concurrently accessing
a file from a different server, either locally or via a NFS mount, then mandatory share mode
locks and oplocks are ineffective, because the local server smbd processes are not
coordinating exclusive file access. UNIX byte range locking is propagated over NFS, so it
will work over multiple NFS mounts. In these cases, disable oplocks, and enable share mode
and byte range.
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = no
Note: It is not recommended to NFS mount a remote file system from the CIFS/9000 server
for Windows client access. Performance could be affected.
19
6.3 WINDOWS AND UNIX CLIENT ACCESS – Local File
CIFS/9000
Clients
System
Windows
File
The diagram above shows a Windows client and a UNIX client requesting concurrent file
access on the CIFS/9000 server to a local file system. The key issue for this configuration is
understanding when the client platform locking schemes can or cannot interoperate.
A UNIX process is not aware of Windows Mandatory Share Mode (Open Mode) locking.
Therefore, a Windows client may lock a file with Mandatory Share Mode locks, but the UNIX
process may concurrently open and read or write to the file, despite the Windows client file
locks. CIFS/9000 has been enhanced to translate Windows Mandatory Share Mode
locks into byte range locks, thus providing locking interoperation with the UNIX
advisory locking protocol and reducing the risk of data corruption.
.
Remember: competitors claim their Mandatory Share Mode locking interoperability
mechanism provides comprehensive protection from UNIX/NFS concurrent file
access, even if they do not participate in the advisory locking protocol. However, if a
UNIX/NFS application is not properly coded to lock files, then there is no way to
protect other UNIX/NFS processes from concurrent file access data corruption. If
data can be corrupted by UNIX/NFS concurrent file access, then providing Windows
Share Mode (open mode) locking protection from those same UNIX/NFS processes
UNIX
PC-NFS
CIFS/9000
Windows
NFS
20
(mixed-mode access) does not remove the element of risk from data corruption
because the locking interoperability is not comprehensive system-wide5.
Byte Range locking is implemented for both Windows and UNIX access with UNIX advisory
byte range locking via the fcntl function. Since UNIX byte range locking is advisory, a UNIX
process must be properly coded to participate in the locking protocol. The CIFS/9000 smbd
process actually calls the UNIX fcntl function to implement Windows byte range locking.
When both processes correctly interact, byte range locking is fully effective in a mixed
Windows-UNIX access environment. Byte range locking should remain enabled.
Opportunistic (Oplocks) locking should be disabled for any share that has mixed Windows
and UNIX client access. A UNIX process has no concept of an oplock, therefore cannot send
an oplock break when a Windows client has cached a copy of a file. A UNIX process could
open and write to a disk file that has been modified in the Windows client cache, which
results in an unacceptable risk of data corruption. Oplocks should be disabled in a mixed
Windows-UNIX access environment.
Mandatory, Byte Range, and Opportunistic locking are all enabled by default. Disable
oplocks for Windows-UNIX share file access explicitly on a per -share basis by editing the
smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = no
veto oplocks can be used to specify particular files on a share that will encounter mixed
Windows and UNIX access, and prevent the CIFS/9000 server from granting oplock requests
upon those files. By enabling veto oplocks for mixed-mode shared access, Windows clients
can continue to utilize oplocks for Windows-only shared access and gain the performance
benefit of file caching.
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
veto oplock files = /filename.ext/
5
See Appendix B.5
21
6.4 WINDOWS AND UNIX CLIENT ACCESS – NFS
CIFS/9000
Mounted File System
Windows
File
The diagram above shows a Windows client and a UNIX client requesting concurrent file
access on the CIFS/9000 server to a NFS mounted file system. The key issue for this
configuration is understanding when the client platform locking schemes can or cannot
interoperate.
A UNIX process is not aware of Windows Mandatory Share Mode (Open Mode) locking,
regardless of the NFS mount. A Windows client may lock a file on the CIFS/9000 server (in
this case the server is also an NFS client) with Mandatory Share Mode locks, but the lock is
not propagated over the NFS mount. CIFS/9000 has been enhanced to translate
Windows Mandatory Share Mode locks into byte range locks, thus providing
locking interoperation with the UNIX advisory locking protocol and reducing the
risk of data corruption. Windows applications expect mandatory share mode locking to be
enabled, so share mode locking should remain enabled.
Remember: competitors that claim their Mandatory Share Mode locking
interoperability mechanism provides comprehensive protection from UNIX/NFS
concurrent file access, even if they do not participate in the advisory locking
protocol. However, if a UNIX/NFS application is not properly coded to lock files,
then there is no way to protect other UNIX/NFS processes from concurrent file
access data corruption. If data can be corrupted by UNIX/NFS concurrent file
access, then providing Windows Share Mode (open mode) locking protection from
UNIX
Clients
PC-NFS
CIFS/9000
Windows
NFS
22
those same UNIX/NFS processes (mixed-mode access) does not remove the element of
risk from data corruption because the locking interoperability is not comprehensive
system-wide6.
Byte Range locking is implemented for concurrent Windows and UNIX access with UNIX
advisory byte range locking via the fcntl function, and NFS propagates the locks over the
NFS mount to the disk file. Since UNIX byte range locking is advisory, other processes
accessing the file must be properly coded to participate in the locking protocol. The
CIFS/9000 smbd process actually calls the UNIX fcntl function to implement Windows byte
range locking. Thus, a Windows client accessing a NFS mounted file on a CIFS/9000 share
using Windows byte range locks will interoperate with other Windows clients using byte
range locks (even from other CIFS/9000 servers) or with UNIX processes that are properly
coded to participate in the byte range locking protocol. When both processes correctly
participate in UNIX advisory locking, byte range locking is fully effective in a mixed
Windows-UNIX NFS client environment. Byte range locking should remain enabled.
Opportunistic (Oplocks) locking should be disabled for any share that has mixed Windows
and UNIX client access, regardless of an NFS mount. UNIX and NFS have no concept of an
oplock, therefore cannot send an oplock break when a Windows client has cached a copy of a
file. A UNIX process could open and write to a disk file that has been modified in the
Windows client cache, which results in an unacceptable risk of data corruption. Oplocks
should be disabled in a mixed Windows-UNIX access environment, regardless of NFS usage.
Mandatory, Byte Range, and Opportunistic locking are all enabled by default. Disable
oplocks for Windows-UNIX share file access explicitly on a per -share basis by editing the
smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = no
veto oplocks can be used to specify particular files on a share that will encounter mixed
Windows and UNIX access, and prevent the CIFS/9000 server from granting oplock requests
upon those files. By enabling veto oplocks for mixed-mode shared access, Windows clients
can continue to utilize oplocks for Windows-only shared access and gain the performance
benefit of file caching.
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
veto oplock files = /filename.ext/
6
See Appendix B.5
23
6.5 WINDOWS AND UNIX/NFS CLIENT ACCESS – Local
CIFS/9000
and NFS Mounted File Systems
Windows
File
The diagram above shows a Windows client and a UNIX/NFS client requesting concurrent
file access on the CIFS/9000 server. The key issue for this configuration is understanding
when the client platform locking schemes can or cannot interoperate.
A UNIX/NFS process is not aware of Windows Mandatory Share Mode (Open Mode) locking.
Therefore, a Windows client may lock a file with Mandatory Share Mode locks, but the
UNIX/ NFS process may concurrently open and read or write to the file, despite the Windows
client file locks. CIFS/9000 has been enhanced to translate Windows Mandatory
Share Mode locks into byte range locks, thus providing locking interoperation
with the UNIX advisory locking protocol and reducing the risk of data corruption.
Remember: competitors claim their Mandatory Share Mode locking interoperability
mechanism provides comprehensive protection from UNIX/NFS concurrent file
access, even if they do not participate in the advisory locking protocol. However, if a
UNIX/NFS application is not properly coded to lock files, then there is no way to
protect other UNIX/NFS processes from concurrent file access data corruption. If
data can be corrupted by UNIX/NFS concurrent file access, then providing Windows
Share Mode (open mode) locking protection from those same UNIX/NFS processes
UNIX/NFSPC-NFS
Clients
CIFS/9000
Windows
NFS
24
(mixed-mode access) does not remove the element of risk from data corruption
because the locking interoperability is not comprehensive system-wide7.
Byte Range locking is implemented for both Windows and UNIX/NFS access with UNIX
advisory byte range locking via the fcntl function. Since UNIX/NFS byte range locking is
advisory, a UNIX process must be properly coded to participate in the locking protocol. The
CIFS/9000 smbd process actually calls the UNIX fcntl function to implement Windows byte
range locking. When both processes correctly interact, byte range locking is fully effective in
a mixed Windows-UNIX/NFS access environment. Byte range locking should remain
enabled.
Opportunistic (Oplocks) locking should be disabled for any share that has mixed Windows
and UNIX/NFS client access. A UNIX process has no concept of an oplock, therefore cannot
send an oplock break when a Windows client has cached a copy of a file. A UNIX process
could open and write to a disk file that has been modified in the Windows client cache, which
results in an unacceptable risk of data corruption. Oplocks should be disabled in a mixed
Windows-UNIX/NFS access environment.
Mandatory, Byte Range, and Opportunistic locking are all enabled by default. Disable
oplocks for Windows-UNIX share file access explicitly on a per -share basis by editing the
smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = no
veto oplocks can be used to specify particular files on a share that will encounter mixed
Windows and UNIX access, and prevent the CIFS/9000 server from granting oplock requests
upon those files. By enabling veto oplocks for mixed-mode shared access, Windows clients
can continue to utilize oplocks for Windows-only shared access and gain the performance
benefit of file caching.
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
veto oplock files = /filename.ext/
7
See Appendix B.5
25
6.6 WINDOWS AND PC-NFS CLIENT ACCESS – Local
CIFS/9000
Clients
and NFS Mounted File Systems
Windows
File
The diagram above shows a Windows client and a PC-NFS client requesting concurrent file
access on the CIFS/9000 server to a local and/or NFS mounted file system. The key issue for
this configuration is that with PC-NFS, the locking interoperability is the same for a local or
NFS mounted file system, and even for PC-NFS direct access to the NFS file server – as
illustrated above.
PC-NFS implements Mandatory Share Mode (Open Mode) locking through the NFS Network
Lock Manager. This allows PC-NFS to place and honor Mandatory Share Mode locks with
other PC-NFS clients. CIFS/9000 has been enhanced to translate Windows
Mandatory Share Mode locks into byte range locks, thus providing locking
interoperation with the UNIX/NFS advisory locking protocol and reducing the risk
of data corruption. This enhancement works for PC-NFS because of the interoperation in
the NLM. Windows applications expect mandatory share mode locking to be enabled, so
share mode locking should remain enabled on the CIFS/9000 server.
Byte Range locking is implemented for concurrent Windows and PC-NFS access using the
NFS NLM. Since NFS NLM byte range locking is advisory, Windows applications that are
accessing the file must be properly coded to participate in the locking protocol. PC-NFS will
propagate the Windows byte range lock over the PC-NFS mount. The cooperating CIFS/9000
smbd process actually calls the UNIX fcntl function to implement Windows client byte range
locking. Thus, a Windows PC-NFS client accessing a file on a CIFS/9000 share using
UNIX
PC-NFS
CIFS/9000
Windows
NFS
26
Windows byte range locks will interoperate with other Windows clients using byte range
locks or with UNIX processes that are properly coded to participate in the byte range locking
protocol. When both processes correctly participate in the advisory locking protocol, byte
range locking is fully effective in a mixed Windows, PC-NFS, and UNIX client environment.
Byte range locking should remain enabled8.
Opportunistic (Oplocks) locking should be disabled for any share that has mixed Windows
and PC-NFS client access. PC-NFS has no concept of an oplock, therefore cannot send an
oplock break when a Windows client has cached a copy of a file. A PC-NFS client could open
and write to a disk file that has been modified in the Windows client cache, which results in
an unacceptable risk of data corruption. Oplocks should be disabled in a mixed Windows-PCNFS access environment.
Mandatory, Byte Range, and Opportunistic locking are all enabled by default. Disable
oplocks for Windows/PC-NFS share file access explicitly on a per-share basis by editing the
smb.conf file:
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = no
veto oplocks can be used to specify particular files on a share that will encounter mixed
Windows and PC-NFS access, and prevent the CIFS/9000 server from granting oplock
requests upon those files. By enabling veto oplocks for mixed-mode shared access, Windows
clients can continue to utilize oplocks for Windows-only shared access and gain the
performance benefit of file caching.
[share_name]
share modes = yes <default config – shown for example only>
locking = yes <default config – shown for example only>
oplocks = yes
veto oplock files = /filename.ext/
8
See Appendix B.2
27
6.7 WINDOWS AND CIFS/9000 CLIENT – Local and NFS
CIFS/9000
Clients
Mounted File Systems
Windows
File
The diagram above shows a Windows client and a CIFS/9000 client requesting concurrent
file access on the CIFS/9000 server to a local file system and a NFS mounted file system.
The key issue for this configuration is that a CIFS/9000 client has no file locking capability.
The CIFS/9000 client product allows UNIX workstations to connect to CIFS servers (either
native Windows or CIFS/9000) and share files using the CIFS (SMB) protocol. A properly
coded UNIX application that adheres to the advisory locking protocol and is running on the
CIFS/9000 client will call the fcntl byte range locking functions, and those calls will fail due
to the CIFS/9000 client’s inability to propagate those locks to the CIFS protocol. The
application effect of the function failure is dependant upon the application logic. There is no
CIFS/9000 client file locking distinction between a CIFS/9000 server local file system or a
NFS mounted file system: client locking is currently not implemented for either file system.
A CIFS/9000 client should not be allowed concurrent file access with other client access
platforms on either a CIFS/9000 server or a native Windows server.
CIFS/9000 client locking capability is under investigation and will be a HP added-value
feature in the near future. Currently, do not allow concurrent file access.
Note: The HP CIFS/9000 client is based upon the “Sharity” 3rd-party product.
[share_name]
share modes = yes <default config – shown for example only>
UNIX
PC-NFS
CIFS/9000
Windows
NFS
28
locking = yes <default config – shown for example only>
oplocks = no
29
Chapter 7 CIFS/9000 LOCKING SUMMARY
The following table summarizes CIFS/9000 file locking:
Mandatory Share Mode (Open Mode) CIFS/9000
Lock Windows Yes
Lock UNIX – no advisory locking Planned Enhancement9
Lock UNIX – advisory locking
Lock UNIX/NFS – no advisory locking Planned Enhancement9
Lock UNIX/NFS – advisory locking
Lock PC-NFS
Byte Range Locking
Lock Windows Yes
Lock UNIX – no advisory locking Planned Enhancement
Lock UNIX – advisory locking Yes10
Lock UNIX/NFS – no advisory locking Planned Enhancement
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Yes
Oplocks
Break Oplock for Windows access Yes
Break Oplock for UNIX access – no
advisory
Break Oplock for UNIX access - advisory Planned Enhancement
Break Oplock for UNIX/NFS – no advisory Planned Enhancement
Break Oplock for UNIX/NFS – advisory Planned Enhancement
Break Oplock for PC-NFS Planned Enhancement
Yes (HP-UX AR 0901)
Yes (HP-UX AR 0901)
Yes (HP-UX AR 0901)
Planned Enhancement
9
See Appendix B.5
10
See Appendix B.2
30
Chapter 8 CIFS/9000 COMPETITION LOCKING
SUMMARY
CIFS/9000 competitors are comprised of dedicated NAS (Network Attached Storage) file
servers and general purpose UNIX/NT integration servers. Competitor file locking data has
been gathered from the documentation of the competitor’s products and summarized here.
In a future revision of this paper, actual competitor locking test results will be published.
The following products will be examined:
• Network Appliance “Filers”
• EMC Celerra
• Auspex NeTservices
• Veritas File Server Edition
31
8.1 Network Appliance
Network Appliance markets very specific NAS servers that they call “Filers”. Filers are
single-purpose front-end “thin servers” used exclusively for storage access. NetApps employs
a feature called the “SecureShare” cross-protocol Lock Manager. NetApps literature claims
that SecureShare provides comprehensive multi-platform (heterogeneous) file locking
capability.
NetApps servers are single-purpose file servers running a proprietary OS called Data Ontap.
UNIX users and applications do not run on the system. Therefore, UNIX-Windows
concurrent file access is not an issue, and NetApps literature ignores UNIX file sharing
issues - probably for this reason. SecureShare does offer an interoperability mechanism for
Windows and NFS clients. SecureShare can protect Windows clients with Mandatory Share
Mode (open mode) locks from concurrent file access UNIX/NFS applications, even if they do
not participate in the advisory locking protocol. However, if a UNIX/NFS application is not
properly coded to lock files, then SecureShare cannot protect other UNIX/NFS processes from
concurrent file access data corruption. If SecureShare allows data to be corrupted by
UNIX/NFS concurrent file access, then providing Windows Share Mode (open mode) locking
protection from those same UNIX/NFS processes has limited value11.
Based upon Network Appliance documentation, SecureShare provides the following file
locking ability:
Mandatory Share Mode (Open Mode)
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking Yes11
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Yes
Byte Range Locking
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking Yes11
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Yes
Oplocks
Break Oplock for Windows access Yes
Break Oplock for UNIX access – no
advisory
Break Oplock for UNIX access - advisory Not Applicable
Break Oplock for UNIX/NFS – no advisory Yes
Break Oplock for UNIX/NFS – advisory Yes
Break Oplock for PC-NFS Yes
11
See Appendix B.5
Network Appliance
Not Applicable
32
NetApps SecureShare provides Mandatory Share Mode (open mode) locking for concurrent
access with PC-NFS and UNIX/NFS. CIFS/9000 provides this locking feature at the HP-UX
September 2001 Application Release.
NetApps SecureShare provides byte range locking interoperability even for UNIX/NFS
processes that do not participate in the advisory locking protocol. CIFS/9000 has a planned
enhancement scheduled to provide the same locking feature. Please read Chapter 3 and Appendix B to understand the actual significance of this capability.
NetApps SecureShare provides Oplock support for Windows clients with concurrent access
from PC-NFS and UNIX/NFS. SecureShare will send an Oplock break to a Windows client
when a PC-NFS client performs an open on the file, and when a UNIX/NFS client reads or
writes to a file. CIFS/9000 has a planned enhancement scheduled to provide the same locking
feature.
Empirical data will be added when test equipment becomes available.
33
8.2 EMC Celerra
EMC markets its Celerra file server as a NAS front-end to a Symetrix disk array. Celerra is
a single-purpose front-end server used exclusively for storage access to Symetrix. It runs a
proprietary OS called DART that is incapable of running applications, users, or accessing
and interoperating with non -EMC storage devices.
Since Celerra supports no users or applications, UNIX-Windows concurrent file access is not
an issue. EMC documentation about locking behavior of Celerra is vague, but basic behavior
can be surmised by utilizing various documents.
Based upon EMC documentation, Celerra provides the following file locking ability:
Mandatory Share Mode (Open Mode) EMC Celerra
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking Unknown12
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Unknown
Byte Range Locking
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking Unknown12
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Unknown
Oplocks
Break Oplock for Windows access Yes
Break Oplock for UNIX access – no
advisory
Break Oplock for UNIX access - advisory Not Applicable
Break Oplock for UNIX/NFS – no advisory Unknown
Break Oplock for UNIX/NFS – advisory Unknown
Break Oplock for PC-NFS Unknown
EMC Celerra appears to provide Mandatory Share Mode (open mode) locking for concurrent
access with UNIX/NFS when the advisory locking protocol is adhered to. They make no
statement about PC-NFS. CIFS/9000 provides this locking feature at the HP-UX September
2001 Application Release.
EMC Celerra appears to provide byte range locking for UNIX/NFS when the advisory locking
protocol is adhered to. They make no statement about PC-NFS. CIFS/9000 provides byte
range locking for UNIX, UNIX/NFS and PC-NFS.
12
Anecdotal evidence suggests Celerra has this feature. See Appendix B.5
Not Applicable
34
EMC’s Celerra documentation claims support of oplocks, but makes no mention of
UNIX/NFS interoperability. They recommend turning oplocks off when “handling critical
data with the need to avoid even slight data loss”, which implies that they do not
interoperate with UNIX/NFS. CIFS/9000 has a planned enhancement scheduled to provide
UNIX, UNIX/NFS, and PC-NFS oplock support.
Empirical data will be added when test equipment becomes available.
HP Sales Force personnel report that customers have been informed by EMC that Celerra
provides comprehensive cross-platform locking, including:
• Byte Range
• Mandatory Share Mode (Open Mode)
• Non-Locking NFS client
13
Please read Chapter 3 and Appendix B.
13
See Appendix B.5
35
8.3 Auspex NeTservices
Auspex markets a NAS server called 4Front NetServer 2000. Auspex is an Advanced Server
for UNIX OEM customer of AT&T, and their version of Advanced Server is the NeTservices
UNIX/Windows consolidation product, running on UNIX on the 4Front NS 2000 server.
AT&T Advanced Server is also the OEM source for HP’s AS/9000 product.
NeTservices runs on a UNIX operating system, but like NetApps and EMC, appears to be a
single-purpose NAS server. Thus, NeTservices can provide concurrent file access for
Windows and NFS clients, but does not support UNIX users or applications on the server.
NeTservices file locking implementation appears to be based upon Advanced Server for
UNIX, which provides byte range locking interoperability for Windows and NFS. NFS access
must adhere to the advisory locking protocol.
Advanced Server for UNIX also enables oplocks, but for Windows-only client access.
However, enabling oplocks automatically disables UNIX/NFS locks.
Based upon Auspex and Advanced Server documentation, NeTservices provides the following
file locking ability:
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking No
Lock UNIX/NFS – advisory locking No
Lock PC-NFS No
Byte Range Locking
Lock Windows Yes
Lock UNIX – no advisory locking Not Applicable
Lock UNIX – advisory locking Not Applicable
Lock UNIX/NFS – no advisory locking No
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS No
Oplocks
Break Oplock for Windows access Yes
Break Oplock for UNIX access – no
advisory
Break Oplock for UNIX access - advisory Not Applicable
Break Oplock for UNIX/NFS – no advisory No
Break Oplock for UNIX/NFS – advisory No
Break Oplock for PC-NFS No
Auspex NeTservices provides Mandatory Share Mode (open mode) locking for Windows
clients only. CIFS/9000 has a planned enhancement to interoperate Windows Mandatory
Share Mode (open mode) locking with UNIX, UNIX/NFS, and PC-NFS.
Not Applicable
36
NeTservices provides byte range locking for UNIX/NFS when the advisory locking protocol is
adhered to. They make no statement about PC-NFS. CIFS/9000 provides byte range locking
for UNIX, UNIX/NFS and PC-NFS.
NeTservices provides oplocks support for Windows-only file access. Advanced Server for
UNIX oplock support is enabled server-wide, and automatically disables UNIX/NFS byte
range lock support, so oplocks can only be enabled for a purely Windows homogeneous client
environment. CIFS/9000 enables oplocks per-share, so shares that require UNIX and/or
UNIX/NFS locking can co-exist with oplock shares. CIFS/9000 has a planned enhancement
to interoperate Windows oplocks with UNIX, UNIX/NFS, and PC-NFS.
37
8.4 Veritas File Server Edition
Veritas markets a UNIX/NT integration product called File Server Edition that runs on Sun
SPARC Solaris servers. File Server Edition consists of the Veritas File System, Veritas
Volume Manager, Veritas Quicklog, and Samba.
Veritas File Edition literature does not reference file locking capabilities. However, since it
is essentially Samba bundled with other Veritas products, we can reasonably conclude that
the file locking behavior is similar to CIFS/9000 (which is based upon Samba 2.0.6), minus
the planned enhancements.
Based upon Samba documentation, Veritas provides the following file locking ability:
Mandatory Share Mode (Open Mode) Veritas FSE
Lock Windows Yes
Lock UNIX – no advisory locking No
Lock UNIX – advisory locking No
Lock UNIX/NFS – no advisory locking No
Lock UNIX/NFS – advisory locking No
Lock PC-NFS No
Byte Range Locking
Lock Windows Yes
Lock UNIX – no advisory locking No
Lock UNIX – advisory locking Yes
Lock UNIX/NFS – no advisory locking No
Lock UNIX/NFS – advisory locking Yes
Lock PC-NFS Yes
Oplocks
Break Oplock for Windows access Yes
Break Oplock for UNIX access – no
advisory
Break Oplock for UNIX access - advisory No
Break Oplock for UNIX/NFS – no advisory No
Break Oplock for UNIX/NFS – advisory No
Break Oplock for PC-NFS No
Veritas File Server Edition will provide standard Samba locking.
No
38
8.5 Locking Summary Table
Mandatory Share Mode (Open Mode) CIFS/9000 Net Apps EMC Auspex
Lock Windows Yes Yes Yes Yes Yes
Lock UNIX – no advisory locking P/E N/A N/A N/A No
Lock UNIX – advisory locking Yes (0901) N/A N/A N/A No
Lock UNIX/NFS – no advisory locking P/E14 Yes14 U14 No No
Lock UNIX/NFS – advisory locking Yes (0901) Yes Yes No No
Lock PC-NFS Yes (0901) Yes U No No
Lock UNIX/NFS – no advisory locking P/E14 Yes14 U14 No No
Lock UNIX/NFS – advisory locking Yes Yes Yes Yes Yes
Lock PC-NFS Yes Yes U No Yes
Oplocks
Break Oplock for Windows access Yes Yes Yes Yes Yes
Break Oplock for UNIX access – no
P/E N/A N/A N/A No
advisory
Break Oplock for UNIX access - advisory P/E N/A N/A N/A No
Break Oplock for UNIX/NFS – no advisory P/E Yes U No No
Break Oplock for UNIX/NFS – advisory P/E Yes U No No
Break Oplock for PC-NFS P/E Yes U No No
• P/E= Planned Enhancement
• N/A= Not Applicable
• U= Unknown
Veritas
14
See Appendix B5
39
Chapter 9 CIFS/9000 File Locking
Interoperability Summary
A CIFS/9000 server can provide file storage (and printing) for Windows clients, UNIX clients,
NFS and PC-NFS clients, and the CIFS/9000 client. Understanding how the various client
platforms invoke file locking for homogenous and heterogeneous (mixed) client access is
critical when designing and implementing a NAS or technical server configuration.
It is absolutely essential that HP sales force personnel understand the customer
environment to determine if cross-platform file locking is a necessity. It is also
essential that the customer understand that competitor’s claims of protection from
non-locking NFS clients does not provide comprehensive data integrity, because if
one non -locking NFS client can access a file, then two non-locking NFS clients can
access a file, and no vendor can claim data integrity protection for two non -locking
clients.
CIFS/9000 provides secure, comprehensive file locking for homogenous Windows client access
– either locally or over an NFS mount. Mixed client access requires knowledge of how the
various client platform applications and file systems lock files to fully understand how they
will interoperate. Based upon that knowledge, informed decisions can be made about how to
configure the CIFS/9000 for mixed client access, or whether to allow mixed client access, or
whether CIFS/9000 is the correct server platform to implement.
Windows utilizes 3 different file locking mechanisms:
Windows clients unilaterally honor mandatory share mode (open mode) and byte range
locking. Opportunistic locking allows Windows clients to cache files locally, thus enjoying a
significant performance boost due to decreased network latency. Oplocks rely on the ability
of an oplock break to notify the caching client that concurrent access has been requested
from another client, therefore causing the original client to flush all cached data to the file
server.
UNIX/NFS uses Byte Range locking to implement the advisory locking protocol. UNIX/NFS
locking is not mandatory in most cases, and requires that other processes correctly
implement the advisory locking protocol. Byte range locking in this case does not protect a
file from non-locking UNIX/NFS processes.
PC-NFS (as tested with WRQ) utilizes the Network Lock Manager to implement byte range
locking. Thus, PC-NFS also is dependant upon the advisory locking protocol for concurrent
file access, and cannot protect a locked file from access by a non-locking process.
CIFS/9000 implements all aspects of Windows file locking when file access is homogeneous,
Windows-only access.
CIFS/9000 at first release provides interoperability between Windows, UNIX/NFS, and PCNFS clients by implementing the byte range advisory locking protocol. CIFS/9000 will
40
protect Windows clients that have locked files from UNIX/NFS and PC-NFS processes that
implement the byte range advisory locking protocol. CIFS/9000 will not protect Windows
clients from processes that do not adhere to the advisory locking protocol. CIFS/9000 has a
planned enhancement to provide this capability.
CIFS/9000 provides locking interoperability between Windows clients with Mandatory Share
Mode (Open Mode) locks and UNIX/NFS or PC-NFS clients as of the September 2001 HP-UX
application Release15.
Currently, CIFS/9000 will not send Windows Clients an oplock break when a UNIX/NFS or
PC-NFS client requests concurrent file access. CIFS/9000 has a planned enhancement to
provide this capability.
At first release in March of 2000, CIFS/9000 provides comprehensive Windows client file
locking interoperability, and byte-range locking interoperability for UNIX/NFS and PC-NFS
clients. At the September 2001 HP-UX Application Release, Windows Mandatory Share
Mode (Open Mode) locking interoperability UNIX/NFS advisory locking is added. With the
addition of non-locking protection and oplocks in future enhancements, CIFS/9000 will meet,
and in most cases exceed, its competitors Windows-UNIX/NFS interoperability file system
products.
15
See Appendix B4
41
Appendix A smb.conf Examples
A.1 smb.conf for Windows -Only Access
# Samba config file created using SWAT
# Date: 2000/04/10 12:59:01
# Global parameters
[global]
workgroup = SNSLATC
netbios name = CIFS_SERVER
server string = Samba Server
security = DOMAIN
encrypt passwords = Yes
password server = *
syslog = 0
log file = /var/opt/samba/log.%m
max log size = 1000
local master = No
read only = No
short preserve case = No
dos filetime resolution = Yes
[tmp]
path = /tmp
[cifshare]
comment = CIFS User Home Share
path = /home/cifshare
share modes = yes
locking = yes
oplocks = yes
42
A.2 smb.conf for Mixed-Mode Access
# Samba config file created using SWAT
# Date: 2000/04/10 12:59:01
# Global parameters
[global]
workgroup = SNSLATC
netbios name = CIFS_SERVER
server string = Samba Server
security = DOMAIN
encrypt passwords = Yes
password server = *
syslog = 0
log file = /var/opt/samba/log.%m
max log size = 1000
local master = No
read only = No
short preserve case = No
dos filetime resolution = Yes
[tmp]
path = /tmp
[cifshare]
comment = CIFS User Home Share
path = /home/cifshare
share modes = yes
locking = yes
oplocks = no
43
Appendix B Sales Tool: Locking Technology
Examples
Hewlett-Packard Sales Force personnel must understand the customer’s operating
environment in order to accurately assess their file locking requirements. HP’s competitors
have been very effective in misinforming potential customers about the necessity of crossplatform CIFS/NFS file locking. It is critical that the Sales Force personnel determine if a
customer needs file locking, and then what level of file locking (if any) is required.
B.1 Determine Locking Requirement
HP-UX 11 CIFS/9000 / NFS File Server & Storage
Files Accessed by
Windows Clients
Shared CIFS/NFS
File Access
Files Accessed by
NFS Clients
Locking Needed?Data MgtACLrwxFilename
No data managementNo ACLRead onlyFilename1
No data managementACE on ACLRead/WriteFilename2
PDM, Clearcase, etc…No ACLRead/WriteFilename3
No data managementNo ACLRead/WriteFilename4
YES – Locking Needed
NO
NO
NO
1. Are there files or directories that will be accessed by both CIFS and NFS?
2. How many files or directories, and what kind of data?
3. Will clients have write access to the files or directories?
4. Are there ACLs on the file or directories that manage client access?
5. Is there a data management application that administers access (Clearcase or PDM
server)?
Answering these questions will help to educate the customer about the realistic exposure to
data corruption that exists within their operating environment due to concurrent CIFS/NFS
cross-platform file access. In most cases the actual existing need for cross-platform file
locking will be rare. HP Sales Force personnel must emphasize this point.
44
B.2 Byte Range Locking
Windows and NFS clients invoke byte range locking with API and function calls. These locks
are processed in server user space, where the Windows client locking semantics are
translated by smbd to UNIX fcntl locks and propagated to the Kernel Lock Manager. The
Kernel Lock Manager is the common denominator for the platform locking semantics, which
allows the platform locks to interoperate and guarantee data integrity when the advisory
protocol is adhered to.
CIFS/9000 implements cross-platform CIFS/NFS byte range locking.
45
B.3 Mandatory Share Mode (Open Mode) Locks
CIFSNFS
Open Mode Locks DO NOT
Interoperate at KLM!
Previously, CIFS/9000 Mandatory Share Mode (Open Mode) locks were processed and
managed by the Samba Internal Locking Mechanism only. They were not translated into the
UNIX fcntl call and propagated to the Kernel Lock Manager. Therefore, Mandatory Share
Mode (Open Mode) locks did not interoperate with NFS Byte Range locks at the KLM, and
data corruption could result in those cases where concurrent file access by both CIFS and
NFS clients was probable
See Appendix B4 for HP’s enhancement for this issue.
CIFS/NFS Open Mode Locking
Old Behavior pre-Sept 2001
Open Mode LockByte Range Lock
Samba
User space
Kernel spaceKernel space
Samba Internal
Locking
Mechanism
HP-UX 11
NLM
Network Lock
Manager
User space
KLM
Kernel Lock
Manager
JFS 3.3 File System
46
B.4 Mandatory Share Mode (Open Mode) Enhancement
CIFSNFS
Translate Open Mode Locks
to Byte Range Locks!
CIFS/9000 has been enhanced to translate Windows Mandatory Share Mode (Open Mode)
locks into UNIX Byte-Range locks using the fcntl function. The resulting Byte-Range locks
will interoperate in the KLM with NFS Byte-Range locks, and data integrity will be provided
for concurrent CIFS/NFS cross platform file access when the advisory locking protocol is
adhered to. This is the most useful locking feature for providing additional data integrity for
HP’s customers that will be accessing a common file set from Windows and NFS clients.
CIFS/NFS Open Mode Locking
New– HP-UX AR 0901
Open Mode LockByte Range Lock
Samba
User space
Kernel spaceKernel space
Samba Internal
Locking
Mechanism
Byte Range Lock
HP-UX 11
NLM
Network Lock
Manager
User space
KLM
Kernel Lock
Manager
JFS 3.3 File System
47
B.5 Competitor’s Claims for NFS Non -Locking Protection
Competitors claim to protect their CIFS clients from NFS clients that are not participating in
the advisory locking protocol. Their claim is based upon their mechanism of comparing every
NFS read and write operation with locking records in the Kernel Lock Manager (or similar
lock manager). The KLM will record every outstanding lock that is held by a CIFS or NFS
client. If a non -locking NFS client attempts a write to a file, the write location will be
compared against lock records in the KLM. If that file is already locked, the operation will
fail. This mechanism works well for that case. Howev er, the figure below illustrates how
data integrity is at risk even with their protection mechanism:
1. If NFS clients B and/or C have a file cached (like in vi), a CIFS client or locking
NFS client can lock the file. Since the KLM has no record of A or B access, it
grants the lock. Now client A and/or B have “stale” data.
2. If one non-locking NFS client has access to a file, then two or more non-locking
NFS clients have access to a file.
a. Client B can overwrite C causing data corruption
b. Client C can overwrite B causing data corruption.
An HP bid for a customer deal should not be won based upon this file locking issue. This file
locking functionality does not provide any real protection from data corruption.
48
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.