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.
Locks are otherwise removed automatically by NSM.
Caution
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.
Note
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.
To list all locks held by NFSv3 and NFsv4 clients on a given path and to release them:
-
From the left navigation menu, select Element Store.
-
On the Element Store page, select the NFS Locks tab.
-
If you want to list locks for a non default tenant, select the relevant tenant from the Tenant dropdown.
-
In the Enter NFS Lock Path field, enter the path to the locked file. This is the filepath on the cluster's NFS server, which is formed as:
<view>/<filename>, where<view>is the NFS-enabled view on the tenant, and<filepath>is the path to the file locked by the client, relative to the mount point.For example, supposing we created a view called
/ExportExampleand we mounted the view onto a client directory called/DirectoryExample. Suppose we create and lock a file under/DirectoryExamplecalledexamplefile. To search for that lock, we need to search for the file path/ExportExample/examplefileon the cluster's NFS server. -
Click Find Locks.
Any locks on the specified file are listed.
The following details are displayed:
Field
Description
Lock Path
The path to the locked file.
Lock Type
-
LOCK_TYPE_NLM4. NLM4 locks taken by NFSv3 clients.
-
LOCK_TYPE_NFS4. NFS4 locks taken by NFSv4.1 clients.
Create Time
The time the lock was acquired.
Caller
An identifier of the the client that acquired the lock. This could be an IP or host name of the client.
Owner
An identifier internal to the client kernel for the specific process that owns the lock.
Exclusive
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.
Granted Type
The type of delegation granted to the client .
-
READ. No other client has the ability to write to the file for the duration of the delegation.
-
WRITE. no other client has read or write access to the file for the duration of the delegation.
Offset
The number of bytes from the beginning of the file's byte range from which the lock begins.
Length
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.Svid
A kernel identifier of the owning process on the client machine.
State
The lock's state ID.
Client ID
The lock's client ID.
Open ID
The lock's open ID.
LOCK ID
The lock's LOCK ID.
-
-
If you want to release locks on the path, click Release all nfs locks on the given path.
All the locks listed are removed from the VAST Cluster NFS server.
To manage NFS locks via CLI, use the following commands.
Tip
For full CLI command syntax, including VAST arguments, enter the command at the CLI prompt in the <command> <subcommand> format provided in the table, followed by ?.
|
To do this task... |
...Use this command |
|---|---|
|
View all NFS locks on a file |
|
|
Delete all NFS locks on a file |
|
NSM monitors the network to detect if hosts that held NLM locks on files have rebooted. When a host reboots, locks are automatically released, enabling the host to lock again.
NSM requires every client host to be configured to send sm_notify reboot notifications to NFS peers.
Once this configuration is done, there is no need to manually release any NLM locks, with the exception of locks that were made before upgrade to VAST Cluster 2.0.0 or a later release. Any locks that were made before upgrade to 2.0.0 will not be removed by NSM and can be released manually through the VAST Web UI or VAST CLI.
To enable sm_notify reboot notifications using a static IP network configuration, do this on each client host:
-
Define a local static IP on the network interface. For example:
$ cat /etc/sysconfig/network-scripts/ifcfg-bond0 # generated by configure_network.py DEVICE=bond0 NAME=bond0 TYPE=Bond BONDING_MASTER=yes ONBOOT=yes BOOTPROTO=none BONDING_OPTS="mode=balance-xor miimon=100 xmit_hash_policy=layer2+3" MTU=9216 IPADDR=192.0.2.20 NETMASK=255.255.255.0 GATEWAY= DNS1= PEERDNS=yes
-
Edit /etc/nfs.conf to enable
sm-notifyon the above configured IP:$ cat /etc/nfs.conf ... [sm-notify] #debug=all # retry-time=900 # outgoing-port= outgoing-addr=192.0.2.20 # lift-grace=y
That's it! Now the client will send notifications on reboot and any files locked by the client will automatically be released.
Comments
0 comments
Article is closed for comments.