HP CIFS File Locking Interoperation

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-wide

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/

See Appendix B.5