Multi-protocol File Locking

StorNext NAS allows you to enable Network File Sharing (NFS) and Server Message Block (SMB) sharing of StorNext file systems (SNFS) using Quantum-supplied NFS and SMB software.

You can export a native SNFS client as:

• An SMB/samba share.
• A NFS exported directory.

You can also mount a native SNFS SAN or LAN client, as well as an Xsan client.

There are three access methods (AM) you can use to access SNFS data:

• SMB
• NFS
• Native SNFS (LAN or SAN clients)

Prior to StorNext 6.2, concurrent access using different AMs was not supported. The following problems existed:

• Missing file lock functionality

• Issues with Samba and NFS server fail-overs or restarts
• Differences in data and directory coherency, for example:
  • oplocks were only known in SMB

A file lock allows you to restrict concurrent access to files and directories. Some examples include:

• A POSIX advisory lock
• An SMB opportunistic locks (oplocks)
• A Windows Mandatory lock
• Windows Sharemodes allow you to deny or allow certain access
• Other methods, for example:
  • Creating, deleting, or I/O on “status” files or directories
  • Changing the permission or access of certain directories

Below is an example of how a file lock is used as a producer and consumer workflow.

1. An application locks out access and then produces a video stream.

2. Applications to consume on other nodes wait on the application's lock and then read the video stream when unlocked or when their attempt to lock succeeds.

The consumer must be able to access the producer’s work. Applications expect data and directory contents to have coherency (in other words, contain what the producer created and wrote) when the lock is released. Each AM has different means of providing coherency.

Beginning with StorNext 6.2 and in conjunction with Appliance Controller 2.2.0, the following lock types are supported.

• POSIX advisory locks
  • The NFS server and StorNext SNFS components are integrated.
  • The native SNFS and NFS clients can lock correctly even across NFS server fail-overs.

  Note: POSIX mandatory locks are not supported.

• Below is a table indicating where you can use POSIX Advisory Locks.

  Note: These locks are only applicable on *nix clients and over NFS.

  POSIX Advisory Integrated by AMs	NN3C	NSMC	LNAC	Xsan	WNAC	WRC
  NAS NFS Client (NN3C) *	✓	Not Supported	✓	✓	Not Supported	Not Supported
  NAS SMB Client (NSMC)	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported
  Linux LAN/SAN Client (LNAC)	✓	Not Supported	✓	✓	Not Supported	Not Supported
  Xsan Client (Xsan)	✓	Not Supported	✓	✓	Not Supported	Not Supported
  Windows Native SAN/LAN (WNAC)	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported
  Windows “Re-share” Client (WRC)	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported	Not Supported

  * An NFS client waiting on a POSIX lock with F_SETLKW can take up to 30 seconds to wake-up after the lock is released.

• SMB opportunistic locks (oplocks)
  • These are used by SMB internally by Windows and Linux clients.
  • macOS supports oplocks at the API level but does not use them inside their SMB client implementation.
  • In StorNext 6.2, oplocks are broken or not granted when any other access occurs by an AM. For example:
    • An NFS client
    • A native SNFS client

    • Another SMB client

  Note: Breaking or not granting an oplock helps with cluster coherency.

• Below is a table showing how different AMs operate with oplocks.

  Oplock support by AMs	Function
  NAS NFS Client (NN3C)	Break
  NAS SMB Client (NSMC)	Both
  Linux LAN/SAN Client (LNAC)	Break
  Xsan Client (Xsan)	Break
  Windows Native SAN/LAN (WNAC)	Both
  Windows “Re-share” Client (WRC)	Both

• Quantum provides limited support for the Windows Mandatory locks
  • The locks work between Windows SMB clients
  • The locks also work between Native Windows SNFS clients
  • The locks do not work between SMB and Native SNFS clients

• POSIX and Windows locks are supported but do not interact with one another as expected; if both locks are used on a file at the same time, then the results are indeterminate.

• Below is a table which provides a list of supported Windows Mandatory Lock, ShareModes, and AMs

  Note: Mandatory Windows locks and ShareModes only work on like access methods. Other access methods like NFS or Linux ignore Windows’ specific capabilities.

  Note: SNFS must have GlobalShareMode=Yes for ShareModes to function properly.

  Mandatory Locks and Sharemodes Supported by AMs	NSMC	WNAC	WRC
  NAS SMB Client (NSMC)	✓	Not Supported	Not Supported
  Windows Native SAN/LAN (WNAC)	Not Supported	✓	✓
  Windows “Re-share” Client (WRC)	Not Supported	✓	✓

• Quantum provides support for other methods listed below:
  • Creating, deleting, contents of “status” files
    • With oplocks working, the contents of “status” files should have coherency in StorNext 6.2, with some caveats.
  • Changing the permission and access of certain directories and folders has not changed in StorNext 6.2
  • The support is as good as each AM’s coherency of data and directory contents

The following are significant differences between NFS, SMB, and native SNFS:

• Native SNFS is the most coherent of the three access methods. Directory and data contents are available immediately.
• The SNFS’ coherency model and SMB’s oplocks are integrated.
  • This helps data coherency where oplocks are used, but directory contents and file/directory attributes can be stale on SMB clients.
• The data coherency has been verified (with three caveats) between:

  • NFS and SMB (NSMC)

  • SMB (NSMC) and native SNFS

  • SMB (NSMC) with other SMB clients

• Caveat 1: The SMB folder contents depends on the platform:
  • The folder cache can be several seconds old.
  • A file created over NFS or native SNFS may not appear for 5-10 seconds on a Windows or macOS SMB client

  • macOS has mixed results with stale directories and prior to macOS 10.14, directories have been known to stick on empty

    Note: A file created in that directory fixes this issue.

• Caveat 2: NFS caches data, file attributes, and directory contents
  • Refreshes are fairly frequent
  • The NFS coherency is loose

  • Quantum recommends you insert a delay or retries on directories

    Note: The delay needed is not as significant as with SMB

  • Similarly for data contents on files. If a lock is released/obtained, NFS I/O might lag
  • NFS does not lock or hold any locks when reading or writing files

• Below is a table which provides a list of supported data and directory coherency with different AMs. Caveat 3 is indicated by the *, **, and ***.

  Coherency Supported by AMs	NN3C	NSMC	LNAC	Xsan	WNAC	WRC
  NAS NFS Client (NN3C) *	✓	✓	✓	✓	✓	✓
  NAS SMB Client (NSMC) **	✓	✓	✓	✓	✓	✓
  Linux LAN/SAN Client (LNAC)	✓	✓	✓	✓	✓	✓
  Xsan Client (Xsan)	✓	✓	✓	✓	✓	✓
  Windows SNFS SAN/LAN (WNAC) ***	✓	✓	✓	✓	✓	✓
  Windows “Re-share” Client (WRC) ***	✓	✓	✓	✓	✓	✓

  • * Coherency is as good as NFS provides
  • ** Coherency is limited by SMB implementation of the client OS’ implementation
    • Directory contents can be stale for many seconds
    • Network disconnect or other errors can result in failed operations.
  • *** There are known limitations.

The following parameters are the minimum required in the configuration file, nfs.conf, on the macOS NFS client for lock reclaims to function.