In order to help NFSv3 clients protect NFS files from data consistency conflicts, VAST Cluster supports NLMv4 locks. NFS client applications can acquire read or write NLM locks on byte ranges or on whole files.
VAST Cluster leverages StorageClassMemory to persist lock information directly within the file system metadata tree. This reduces lock latency and ensures that all nodes have instant access to the current lock state of any file. There is no limit to the number of files that can have locks within the file system. However, because locks occupy a portion of a file's metadata structure, there is a limit on the number of locks that can simultaneously be held on a given file. This limit varies based on the length of the host names holding a lock.
As a rough guideline, up to 100,000 locks can be held per file when the host name is 40 characters in length.
VAST Cluster enables you to remove NLM locks from the VAST Cluster NFS server. This feature is designed to help you in the event that a client OS crashes and leaves behind locks. It releases the locks from the file and enables another client to lock the file.
From VAST Cluster 2.0.0, locks are removed automatically by NSM. Only locks that were leftover by crashes that happened before upgrade to VAST Cluster 2.0.0 or before enabling the client to notify NFS peers on reboot require manual removal.
Do not remove locks from the server when the client application that locked the files is still active. Once the lock is removed from VAST Cluster's NFS server, another client application will be able to acquire another lock on the same byte range.
NLM locking is advisory. Advisory locking keeps track of which files and byte ranges have been locked by which process, but does not prevent a process from writing to a file that is locked by another process. A process can ignore an advisory lock if the process has adequate permission.
From the left navigation menu, select Element Store.
On the Element Store page, select the NLM Locks tab.
The NLM Locks dialog appears.
In the NLM Locks dialog, enter the path to the locked file. This is the filepath on the NFS server, which is formed as:
<export>is the NFS export on the VAST Cluster NFS server, and
<filepath>is the path to the file locked by the client, relative to the mount point.
For example, supposing we created an export called
/ExportExampleand we mounted the export onto a client directory called
/DirectoryExample. Suppose we create and lock a file under
examplefile. To search for that lock, we need to search for the file path
/ExportExample/examplefileon the NFS server.
Any locks on the specified file are listed. For example:
The following details are displayed:
The time the lock was acquired.
An identifier of the the client that acquired the lock. This could be an IP or host name of the client.
An identifier internal to the client kernel for the specific process that owns the lock.
Whether the lock is an exclusive (write) lock or a shared (read) lock.
Yes. The lock is an exclusive or write lock acquired by the client.
No. The lock is a shared, or read, lock. Many clients can access the file to read it, but no client may write to the locked byte range.
The number of bytes from the beginning of the file's byte range from which the lock begins.
The number of bytes of the file locked by the lock. A length of 0 means the lock reaches until the end of the file.
If both offset and length are
0, the entire file is locked.
A kernel identifier of the owning process on the client machine.
Click Remove Locks.
All the locks listed are removed from the VAST Cluster NFS server.
To manage NLM locks via CLI, use the following commands.
For full CLI command syntax, including arguments, enter the command at the CLI prompt in the <command> <subcommand> format provided in the table, followed by ?.
Article is closed for comments.