logo
Manual Pages
Table of Contents

NAME

lock - manage lock records

SYNOPSIS

lock status -f [file] [-p protocol] [-n] lock status -h [host [-o owner]] [-f file] [-p proto] [-n] lock status -o [-f file] [-p proto] [-n] (not valid for NLM and NFSv4) lock status -o owner [-f file] [-p proto] [-n] (CIFS only) lock status -p protocol [-n] lock status -n lock break -f file [-o owner -h host] [-p proto] lock break -h host [-o owner] [-f file] [-p protocol] lock break -o owner [-f file] [-p protocol] (CIFS only) lock break -p protocol lock break -net network Note: Unless a protocol name is specified above, the syntax is valid for all protocols. Output of lock status -p protocol and lock status -p protocol -f are identical. Currently, lock break -f file is allowed, but not recommended because breaking NFSv4 locks might lead to unexpected results on the client. The breaking of NFSv4 locks can be prevented by mentioning the protocol along with the file name. Unlike the case of file name, Host and owner differ in meaning across protocols. Owner is a pertinent filter for CIFS, NLM, and FLEXCACHE only. If protocol is not specified, then locks across all protocols, viz., CIFS, FLEXCACHE, NLM (Nfsv2/Nfsv3), NFSv4, FIO, and WAFL are scanned. In that case, protocols not recognizing the syntax of host or owner generate syntax errors. In the specific cases of NLM and NFSv4, locks cannot be filtered just by specifying owner. Host must be specified along with owner. Owner, being a pid/uid, is not unique unless host (client) is also specified. The same restrictions apply when specifying a set of locks to be broken. Currently, all protcols filter locks by file, but only CIFS, NFSv4
and NLM protocols filter locks by host and owner. NOTE: In the case of NLM, the value of host could be either a hostname (FQDN, hostname alias, etc.,) or an IP address. The lock command does not resolve the hostname to an IP address. Functionally, filtering locks by a hostname is not equivalent to filtering locks by the corresponding IP address. If the locks are to be filtered by host, then the value of host should be obtained from the lock status -h output. Such a value of host should not be interpreted in any way. If done so, may lead to improper status or removal of locks.

DESCRIPTION

lock status prints protocol lock records whereas lock break breaks locks as per the specified options. The options are described as follows:

OPTIONS

-f
Prints lock records organized by file.
-f
file Prints or breaks locks of specified file. The syntax of the file-name is a path name prefixed by "/vol/volX" where volX is the name of a volume on the filer.
-h Prints lock records grouped by host-name.
CIFS, however, does not group locks by host but instead prefixes each record by "CIFS host=" string.
-h host Prints or breaks locks of a specified
host. Currently, only CIFS, NFSv4 and NLM can do this. Note: Meaning of host varies across protocols (CIFS: NetBIOS or FQDN or IP, NLM and FLEXCACHE: IP or FQDN, NFSv4: IP).
-o
Prints lock records grouped by owner-name. CIFS, however, does not group locks by owner but instead prefixes each record by "CIFS owner=" string.
-o
owner Prints or breaks locks of specified owner. Currently, only CIFS does this. NLM and NFSv4 allow specification of owner, but only in the case in which host is specified as well. Note: Meaning of owner varies across protocols (CIFS: [domain\]user, FLEXCACHE: IP:fsid of caching filer, NLM: Process-ID, NFSv4: UID)
-p protocol Prints or breaks locks of specified
protocol, which is a case-insensitive string and can take one of the following values: nlm, nfsv4, cifs, flexcache.
-n Prints the number of share-level and
byte-level locks for each protocol. If specified with "-p <protocol>" switch, it prints the same for the specified protocol only.
-net network Breaks locks of the specified network family,
which is a case-insensitive string and can take one of the following value: IPv4 or IPv6. Currently, only valid for NLM.
lock status -f is one way to output lock records across all protocols , grouping locks by file. A header of form ========<fsid>:<fid> starts the lock dump for each file where fsid and fid uniquely identify the file. Other ways to output lock records across all protocols are: lock sta_tus -h (group by host) and lock status -o (group by owner). An example showing locks grouped by file is: 
  filer> lock status -f
  ========0e1d66f7:00000040
    state=GRANTED mode=FIO_NoDelete
    state=GRANTED mode=FIO_NoDelete
  ========0e1d66f7:00000062
    state=GRANTED mode=FIO_NoDelete
  ========0e1d66f7:000000d3
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=Oplock-Excl oplock=Excl
  ========0e1d66f7:000009d8
    state=GRANTED mode=FIO_NoDelete
  ========0e1d66f7:00000aab
  CIFS path=\another.doc(/vol/vol0/share2/another.doc) host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=RdWr-denyN oplock=None
  CIFS path=\another.doc(/vol/vol0/share2/another.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED
  CIFS path=\another.doc(/vol/vol0/share2/another.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED
  CIFS path=\another.doc(/vol/vol0/share2/another.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED
  NLM[zhora.eng.mycompany.com,6892]: 0:0 1 GWAITING (0x61cc5aa0)
The above output shows locks on 5 files with the last one having both CIFS and NLM locks. As for lock break , there is no way to break locks across all protocols. Locks can be broken for a specified protocol using -p protocol option, though. CIFS style locks follow the format as shown in the example below: 
  filer> lock status -p cifs
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=RdWr-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED
  CIFS path=\another.doc(/vol/vol0/share2/another.doc) host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=Oplock-Excl oplock=Excl fsid=0x0e1d66f7 fileid=0x00000aab
Unlike other protocols, CIFS does not group lock records by file, host, or owner. Instead, each dumped lock record is prefixed by "CIFS <field>=" where <field> is "path", "host", or "owner" in response to "-f", "-h", or "-o" option respectively. Locks are described either as share level locks (denoted by the keyword state appearing in the line) or as byte level locks (which have "offset", "len", and "excl" fields). The first line in the example above is a share level lock and has the following format:
path
CIFS path name of the file or directory associated with the lock followed by the absolute ("/vol/volX" style) path within parentheses. Undetermined absolute path is denoted by empty parentheses. Note that Delete-On-Close locks have no associated absolute path information available. Absolute path is also unavailable in case of insufficient memory.
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
mode
Relates how the lock responds to requests to modify it, see the ACTION MODES section.
oplock
The level of an oplock on the file: Excl (exclusive), Lvl2 (level 2), and None (none).
host
The name of the client which was issued the lock. It is an IP address followed by a NetBIOS name (if available) within parentheses. If NetBIOS name is unavailable, the name is displayed as an IP address followed by empty parentheses.
owner
The name of the user owning the lock.
fileid
File id on the filer. (only printed with options other than "-f")
fsid
Volume id on the filer. (only printed with options other than "-f")
The second line in the above example is a byte level lock. This line has the same format as that of a share-lock record without "oplock" and "mode" fields, and with the following additional fields:
offset
Starting offset of the byte lock
len
Number of bytes locked
excl
Whether the lock is an exclusive byte-level lock or not
Examples of other ways to output (the above) CIFS lock records are: Lock record keyed (but not grouped) by host: 
  filer> lock status -p cifs -h
  CIFS host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=RdWr-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=Oplock-Excl oplock=Excl fsid=0x0e1d66f7 fileid=0x00000aab path=\another.doc(/vol/vol0/share2/another.doc)
Lock record keyed (but not grouped) by owner: 
  filer> lock status -p cifs -o
  CIFS owner=root host=10.34.17.49(FLOYD-XP) state=GRANTED mode=RdWr-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=administrator host=172.18.2.107(VKUMAR-VPC) state=GRANTED mode=Read-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=administrator host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=administrator host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=root host=10.34.17.49(FLOYD-XP) pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=administrator host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=root host=10.34.17.49(FLOYD-XP) pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=root host=10.34.17.49(FLOYD-XP) pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS owner=root host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Oplock-Excl oplock=Excl fsid=0x0e1d66f7 fileid=0x00000aab path=\another.doc(/vol/vol0/share2/another.doc)
CIFS also allows filtering of lock output by specifying one or more of the following options: -f <file> , -h <host> , and -o <owner> . Examples of filtering lock output based on the above CIFS lock records are: Lock record filtered by specified NetBIOS host name: 
  filer> lock status -h vkumar-vpc -p cifs
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
Lock record filtered by specified IP address: 
  filer> lock status -h 10.34.17.49 -p cifs
  CIFS host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=RdWr-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=Oplock-Excl oplock=Excl fsid=0x0e1d66f7 fileid=0x00000aab path=\another.doc(/vol/vol0/share2/another.doc)
Lock record filtered by specified user (CIFS owner): 
  filer> lock status -o administrator -p cifs
  CIFS host=172.18.2.107(VKUMAR-VPC) state=GRANTED mode=Read-denyN oplock=None fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
  CIFS host=172.18.2.107(VKUMAR-VPC) pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED fsid=0x0e1d66f7 fileid=0x000000d3 path=\word.doc(/vol/vol0/share1/word.doc)
Lock record filtered by specified file: ( NOTE: fileid and fsid fields are replaced by a header: "========0e1d66f7:000000d3", as done in lock status -f command described earlier) 
  filer> lock status -p cifs -f /vol/vol0/word.doc
  ========0e1d66f7:000000d3
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root state=GRANTED mode=RdWr-denyN oplock=None
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator state=GRANTED mode=Read-denyN oplock=None
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483481 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483521 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483539 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=172.18.2.107(VKUMAR-VPC) owner=administrator pid=65279 offset=2147483540 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483559 len=1 excl=yes state=GRANTED
  CIFS path=\word.doc(/vol/vol0/share1/word.doc) host=10.34.17.49(FLOYD-XP) owner=root pid=65279 offset=2147483599 len=1 excl=yes state=GRANTED
Lock record filtered by owner, host, and file : 
  filer> lock status -o root -h floyd-xp -p cifs -f /vol/vol0/another.doc
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Oplock-Excl oplock=Excl fsid=0x0e1d66f7 fileid=0x00000aab path=\another.doc(/vol/vol0/share2/another.doc)
As for lock break -p cifs sub-command, the syntax is similar to that of lock status -p cifs with respect to additional options. It also allows breaking of locks using one or more of the following options: -f <file> , -h <host> , and -o <owner> . NLM style locks follow the format: 
  toaster*> lock status -f
  ========b1000060:0007a88d
   simcity1775 state=GONE mode=Writ-denyA
  ========b10000600020e940
   simcity1773 00 1 GRANTED (0xbe89ebd8)
The first line of each dumped lock starts with `=' characters and gives the fsid and fileid of the file being locked. The third line is an example of a share level lock on a file:
host
The name of the client which was issued the lock.
pid
Process ID assigned by the client.
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
mode
Relates how the lock responds to requests to modify it, see the ACTION MODES section.
The fifth line is an example of a byte level lock on a file:
host
The name of the client which was issued the lock.
pid
Process ID assigned by the client.
byte offset
Start of the byte lock
number of bytes
exclusive
Whether the lock is exclusive or not
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
lock address
NFSv4 style locks follow the format: 
  filer> lock status -f
  ========4292014d:0000007e
  NFSv4[IP=172.16.28.73,0]:  GRANTED mode=RdWr-denyN (0x7e6a9010,ix=2)
  NFSv4[IP=172.16.28.73,0]: 0:0 1 GRANTED  (0x7e6a8f00,ix=3)
The first line of each dumped lock starts with `=' characters and gives the fsid and fileid of the file being locked. The second line is an example of a share level lock on a file:
host
The name of the client which was issued the lock.
UID
UID of the process on the client.
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
mode
Relates how the lock responds to requests to modify it, see the ACTION MODES section.
lock address State ID index The third line is an example of a byte level lock on a file:
host
The name of the client which was issued the lock.
UID
UID of the process on the client.
byte offset
Start of the byte lock
number of bytes
exclusive
Whether the lock is exclusive or not
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
lock address State ID index
-h
Prints lock records organized by host.
CIFS style locks are not grouped by host, so they will not show up under this option. NLM style locks are grouped by host and will show up under this option. They follow the format: 
  toaster*> lock status -h
  ========builder
   1583 0x00e509e10xb1000060 00 1 GRANTED (0xbe89e8b8)
  ========simcity
   1773 0x0020e9400xb1000060 00 1 GRANTED (0xbe89ebd8)
   1775 0x0020e9410xb1000060 state=GONE mode=Writ-denyA
The first line of each dumped lock starts with `=' characters and gives the name of client which has applied the lock. The sixth line in the example above illustrates the format followed by share level locks:
pid
Process ID assigned by the client.
fileid
File id on the filer.
fsid
Volume id on the filer.
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
mode
Relates how the lock responds to requests to modify it, see the ACTION MODES section.
The second line in the example above illustrates the format followed by byte level locks:
pid
Process ID assigned by the client.
fileid
File id on the filer.
fsid
Volume id on the filer.
byte offset
Start of the byte lock
number of bytes
exclusive
Whether the lock is exclusive or not
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
lock address
Examples of filtering lock output based on a different parameters are shown below:
Lock records keyed (but not grouped) by host: 
  filer> lock status -p NLM -h
  ======== NLM host darla.lab.mycompany.com
   3082 0x3ef4bff6:0x000001cf 0:0 1 GRANTED (0x7ead8ac0)
   2988 0x3ef4bff6:0x000001ce 0:0 1 GRANTED (0x7ead88a0)
  ======== NLM host kendra.lab.mycompany.com
   1914 0x3ef4bff6:0x000001cf 0:0 1 GWAITING (0x7ead89b0)
Lock record filtered by specified (client) host name: 
  filer> lock status -p NLM -h darla.lab.mycompany.com
  ======== NLM host darla.lab.mycompany.com
   3082 0x3ef4bff6:0x000001cf 0:0 1 GRANTED (0x7ead8ac0)
   2988 0x3ef4bff6:0x000001ce 0:0 1 GRANTED (0x7ead88a0)
Lock record filtered by specified (client) host name and owner and owner: 
  filer> lock status -p NLM -h darla.lab.mycompany.com -o 3082
  ======== NLM host darla.lab.mycompany.com owner 3082
     0x3ef4bff6:0x000001cf 0:0 1 GRANTED (0x7ead8ac0)
NFSv4 style locks are grouped by host and will show up under this option. They follow the format: 
  filer> lock status -h
  ======== NFSv4 host 172.16.28.73
  ========NFSv4 client IP=172.16.28.73 client-id=0x42952fa1/0x00010000
     ====== Lock owner: 00000000/0000000B/00001556/07458F08
      0  0x4292014d:0x0000007e 0:0 1 GRANTED  (0x7e6a8f00,ix=2)
     ====== Open owner: 00000000/00000028
      0  0x4292014d:0x0000007e  GRANTED mode=RdWr-denyN (0x7e6a9010,ix=1)
The first line of each dumped set of locks starts with `=' characters and gives the IP address of client which has applied the lock. The second line of each dumped set of locks starts with `=' characters and gives the IP address and NFSv4 clientid info of the client which has applied the lock. The third and fifth line in the example start with `=' characters and gives the NFSv4 owner information of the entity on the client which has applied the lock. Each subset of locks held by a particluar owner will begin with this owner information. The sixth line in the example above illustrates the format followed by share level locks:
UID
UID of the process on the client.
fileid
File id on the filer.
fsid
Volume id on the filer.
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
mode
Relates how the lock responds to requests to modify it, see the ACTION MODES section.
lock address State ID index The fourth line in the example above illustrates the format followed by share level locks:
UID
UID of the process on the client.
fileid
File id on the filer.
fsid
Volume id on the filer.
byte offset
Start of the byte lock
number of bytes
exclusive
Whether the lock is exclusive or not
state
Details what part of the life-cycle the lock is in, see the LOCK STATES section.
lock address State ID index Examples of filtering lock output based on a different parameters are shown below: Lock records keyed (but not grouped) by host: 
  filer> lock status -p NFSv4 -h
  ======== NFSv4 host 172.16.28.73
  ========NFSv4 client IP=172.16.28.73 client-id=0x42952fa1/0x00010000
     ====== Lock owner: 00000000/0000000B/00001556/07458F08
      0  0x4292014d:0x0000007e 0:0 1 GRANTED  (0x7e6a8f00,ix=2)
     ====== Open owner: 00000000/00000028
      0  0x4292014d:0x0000007e  GRANTED mode=RdWr-denyN (0x7e6a9010,ix=1)
Lock record filtered by specified (client) host name: 
  filer> lock status -p NFSv4 -h 172.16.28.73
  ======== NFSv4 host 172.16.28.73
      0  0x4292014d:0x0000007e 0:0 1 GRANTED  (0x7e6a8f00,ix=2)
      0  0x4292014d:0x0000007e  GRANTED mode=RdWr-denyN (0x7e6a9010,ix=1)
Lock record filtered by specified (client) host name and owner and owner: 
  filer> lock status -p NFSv4 -h 172.16.28.73 -o 0
  ======== NFSv4 host 172.16.28.73 owner 0
     0x4292014d:0x0000007e 0:0 1 GRANTED  (0x7e6a8f00,ix=2)
     0x4292014d:0x0000007e  GRANTED mode=RdWr-denyN (0x7e6a9010,ix=1)
-n
Prints the number of locks.
It can either modify the -f or -h options or be used by itself for a quick summary of the numbers of open share and byte locks. It will group the open locks in the protocol categories of CIFS, NLM, NFSv4, WAFL, and TEST. By itself, it will show all of the protocol categories, even if no locks have been issued for that category: 
  toaster*> lock status -n
  CIFS 13 share locks, 3 byte locks
  NLM 1 share locks, 2 byte locks
  WAFL 0 share locks, 0 byte locks
  TEST 0 share locks, 0 byte locks
When issued with either -f or -h for each file which is locked, it shows a summary for only those protocols which have locks issued: 
  toaster*> lock status -n -h
  ========simcity
  NLM 0 share locks, 2 byte locks
  toaster*> lock status -n -f
  ========b1000060:00e509e1
  NLM: 0 share locks, 1 byte locks
  ========b1000060:001d0b21
  CIFS: 1 share locks, 0 byte locks
  ========b0000060:00b129be
  CIFS: 1 share locks, 0 byte locks
lock break -p nlm sub-command breaks all NLM locks and sends notifications to all clients to reclaim locks. lock break -p nlm -h host sub-command breaks all NLM locks for a given host and sends notifications to that host to reclaim its locks. lock break -p nlm -h host -o owner sub-command breaks all NLM locks for the specified owner on the specified host. No notifications (to reclaim removed locks) are sent. Note that lock break sub-command does not always require a protocol name. For example, lock break -f file breaks locks across all protocols for the specified file.

EFFECTIVE

Any changes take effect immediately

VFILER CONSIDERATIONS

lock only operates on locks owned by the vfiler in question.

REFERENCES

TR3024 is a Tech Report which describes the differences between Windows and Unix style locks. It provides an overview and context for the concepts presented in this man page. The report can be found as a white paper, SecureShare: Guaranteed Multiprotocol File Locking at http://www.netapp.com/tech_library/3024.html.

ACTION MODES

The allowed modes are: DelOnClose delete on close semantics SuperLock used for virus scanning (issued to CIFS clients only) Deleg-Read In this case, the client is granted the read delegation. When the filer grants a delegation for a file to a client, the client is guaranteed certain privileges with respect to the sharing of that file with other clients. The filer may provide the client either a read or write delegation for the file. If the client is granted a read delegation, it is assured that no other client has the ability to write to the file for the duration of the delegation. RFC 3530 has more details on delegations. Deleg-Wrt In this case, the client is granted the write delegation. When the filer grants a delegation for a file to a client, the client is guaranteed certain privileges with respect to the sharing of that file with other clients. The filer may provide the client either a read or write delegation for the file. If the client is granted a write delegation, it is assured that no other client has the read or write access to the file for the duration of the delegation. RFC 3530 has more details on delegations. Access-Deny a combination of the following modes on the lock:
access
actions which can be performed on the locks
deny
actions which can be denied on the locks
The various access modes are:
RdWr
can read and write,
Read
can read, but not write,
Writ
can write, but not read,
None
can neither read not write.
The various deny modes are:
denyA
cannot be read or written by others
denyR
cannot be read by others
denyW
cannot be written by others
denyN
can be read and written by others

LOCK STATES

GRANTED
Granted and not being revoked
Locks in this state are on the share-grant or byte-grant lists, depending on type.
REVOKING
Revocation started for this lock
Locks in this state are also on the share-grant or bytegrant lists, depending on type.
GWAITING
Waiting for lock to be granted
Locks in this state are on the share-wait list or one of the wait lists associated with a granted byte lock. Locks enter this state when they can't be granted because of a conflict and the lock parameters indicate that the caller is prepared to wait.
EWAITING
Waiting for lock to be either granted or denied
Locks in this state are on the share-wait list or one of the wait lists associated with a granted byte lock. Locks enter this state when they can't be granted because of a conflict with a soft lock and lock parameters indicate they the caller is not prepared to wait. Generally, in this situation, the protocol is prepared to wait for a limited time to allow the revocation to be resolved so that it can be determined whether the lock is to be granted or denied.
REVOKED
Undergoing revocation and marked by protocol for deletion
This is a transient state whereby the protocol indicates the results of lock revocation to the generic lock manager code. Locks in this state are on the share-grant or bytegrants lists, but are removed immediately.
ADJUSTED
Undergoing revocation and marked by protocol for replacement by a hard lock
This is a transient state whereby the protocol indicates the results of lock revocation to the generic lock manager code. Locks in this state are on the share-grant or bytegrant lists, but are transitioned back to the granted state once the changes in the lock have been dealt with.
DENIED
The lock has been denied
This is a temporary state used to mark locks that have, after waiting, been denied. This is so that when the lock state is noticed by a WAFL operation, appropriate information about the state of the request, including the denial status, will be available. Locks in this state are not in any of the per-file lists.
TIMEDOUT
The wait for the lock has timed out
This is a temporary state used to mark locks that have, after waiting, had the wait timed out. This is so that when the lock state is noticed by a WAFL operation, appropriate information about the state of the request, including the fact that it could not be granted due to a timeout, will be available. Locks in this state are not in any of the per-file lists.
SUBSUMED
Kept in reserve by protocol
This is a transient state used for locks which are one of a set of locks that will take the place of a lock being revoked. Locks in this state are in an internal list and not in any of the per-file lists. They are converted to the GRANTED state and put in the share-grant list as part of completing the revocation operation.
GONE
About to be returned
This is a temporary state for lock objects that are to be freed as soon as any potential references to them are gone. Locks in this state are not on any of the per-file lists.
UNUSED
Just allocated
This is a temporary state for lock objects that have been allocated but have not yet been dealt with (i.e. granted, denied, set up to wait). Locks in this state are not on any of the per-file lists.
Table of Contents