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-PC- NFS 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/

8See Appendix B.2

27

Page 27
Image 27
HP UX Common Internet File System (CIFS) Client/Server Software manual