lock

by Chris Kranz on Jul.07, 2009, under Manual Pages

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

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

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/0×00010000 ====== 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/0×00010000 ====== 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

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)

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