Manual Pages


Table of Contents

NAME

lock - Manages locks 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 is identical.

Warning: When the lock break command completes, any CIFS file handle referencing the affected file will no longer be valid. This may cause unexpected results on the client.

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 protocols 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 node.

-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 node, 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 status -h (group by host) and lock status -o (group by owner).

An example showing locks grouped by file is:

  FAS> 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 durable_state=DH_GRANTED
  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 durable_state=DH_NONE
  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 durable_state=DH_NONE
  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 durable_state=DH_NONE
  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:

  FAS> lock status -p cifs
  CIFS path=\(/vol/vol0/home/) host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 durable_state=DH_NONE
  CIFS path=\(/vol/vol0/home/) host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 durable_state=DH_NONE
  CIFS path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) host= owner= state=GRANTED mode=Oplock-Excl oplock=Lease-RWH fsid=0x6408e411 fileid=0x00001b40 durable_state=DH_NONE
  CIFS path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 durable_state=DH_GRANTED
  CIFS path=\user1(/vol/vol0/home/user1) host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a durable_state=DH_NONE

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).

lease oplock
The level of lease oplock on the file: Lease-RWH (Lease oplock read write batch), Lease-RW (Lease oplock read write), Lease-RH (Lease oplock read batch), Lease-R (Lease oplock read).

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 node (only printed with options other than "-f").

fsid
Volume id on the node (only printed with options other than "-f").

durable_state
State of the durable lock, see the DURABLE STATES section.

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:

  FAS> lock status -p cifs -h
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host= owner= state=GRANTED mode=Oplock-Excl oplock=Lease-RWH fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a path=\user1(/vol/vol0/home/user1) durable_state=DH_NONE

Lock record keyed (but not grouped) by owner:

  FAS> lock status -p cifs -o
  CIFS owner=administrator host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS owner=administrator host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS owner= host= state=GRANTED mode=Oplock-Excl oplock=Lease-RWH fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_NONE
  CIFS owner=administrator host=10.34.17.49(FLOYD-XP) state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED
  CIFS owner=administrator host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a path=\user1(/vol/vol0/home/user1) durable_state=DH_NONE

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:

  FAS> lock status -h floyd-xp -p cifs
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a path=\user1(/vol/vol0/home/user1) durable_state=DH_NONE

Lock record filtered by specified IP address:

  FAS>lock status -h 10.34.17.49 -p cifs
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED
  CIFS host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a path=\user1(/vol/vol0/home/user1) durable_state=DH_NONE

Lock record filtered by specified user (CIFS owner):

  FAS> lock status -o administrator -p cifs
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00000dc8 path=\(/vol/vol0/home/) durable_state=DH_NONE
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=Read-denyN oplock=None fsid=0x6408e411 fileid=0x00001c7a path=\user1(/vol/vol0/home/user1) durable_state=DH_NONE

Lock record filtered by specified file:

( NOTE: fileid and fsid fields are replaced by a header: "========0x6408e411:0x00001c7a", as done in lock status -f command described earlier)

  FAS>lock status -p cifs -f /vol/vol0/home/user1/file1.docx
  ========6408e411:00001b40
  CIFS path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) host= owner= state=GRANTED mode=Oplock-Excl oplock=Lease-RWH durable_state=DH_NONE
  CIFS path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) host=10.34.17.49(FLOYD-XP) owner=administrator state=GRANTED mode=RdWr-denyW oplock=None durable_state=DH_GRANTED

Lock record filtered by owner, host and file:

  FAS>lock status -o administrator -h floyd-xp -p cifs -f /vol/vol0/home/user1/file1.docx
  CIFS host=10.34.17.49(FLOYD-XP) state=GRANTED mode=RdWr-denyW oplock=None fsid=0x6408e411 fileid=0x00001b40 path=\user1\file1.docx(/vol/vol0/home/user1/file1.docx) durable_state=DH_GRANTED

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.

durable_state
State of the durable lock, see the DURABLE STATES 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:

  FAS> 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.

durable_state
State of the durable lock, see the DURABLE STATES 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 node.

fsid
Volume id on the node.

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.

durable_state
State of the durable lock, see the DURABLE STATES 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 node.

fsid
Volume id on the node.

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 different parameters are shown below:

Lock records keyed (but not grouped) by host:

  FAS> 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:

  FAS> 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:

  FAS> 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:

  FAS> 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 client-id 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 particular 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 node.

fsid
Volume id on the node.

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.

durable_state
State of the durable lock, see the DURABLE STATES 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 node.

fsid
Volume id on the node.

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 different parameters are shown below:

Lock records keyed (but not grouped) by host:

  FAS> 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:

  FAS> 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:

  FAS> 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

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 node 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 node 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 node 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 node 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

Write
can write, but not read

None
can neither read nor 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 (that is, granted, denied, set up to wait). Locks in this state are not on any of the per-file lists.

DURABLE STATES

DH_NONE
Durable handle is none.

Durability on the share-level lock is not required.

DH_GRANTED
Durable handle has been granted.

Durability was requested on the file control block and a durable handle was received.

RH_GRANTED
Resilient handle has been granted.

Resiliency was requested on the file control block and a resilient handle was received.

DH_ACTIVE
Durable handle is active.

The file control block preserves durable handle after connection loss and is available for reclaim.

RH_ACTIVE
Resilient handle is active.

The file control block preserves resilient handle after connection loss and is available for reclaim.

DH_PURGED
Durable handle is purged.

The durable handle is purged because a client touched the file or because of administrator action.

DH_CLOSING
Durable handle is being closed.

The durable handle is undergoing close because either it was expired or was purged.

RH_CLOSING
Resilient handle is being closed.

The resilient handle is undergoing close because it was expired.


Table of Contents