logo

Manual Pages

Table of Contents

NAME

lock - manage lock records

SYNOPSIS

lock status [ -f | -h | -n ]

DESCRIPTION

lock status prints protocol lock records organized either by file or by host. A share lock is applied to the whole file, whereas a byte lock is applied to a range of bytes in a file.

OPTIONS

-f
Prints lock records organized by file.

The output is formated differently depending on the protocol which is used to establish the lock.

CIFS style locks follow the format: 

  toaster*> lock status -f
  ========b000006000b4ab07
  \bread\mail.attach\215_00382.pdf
    state=GRANTED mode=Read-denyW oplock=None host=BREAD-W2K
  ========b000006000f28c62
  \bread\docs\newfw_spec.doc
    state=GRANTED mode=RdWr-denyN oplock=None host=BREAD-W2K
   65279 21474835391 1 GRANTED (0xbff9aca0,0x6da68a40,0x2b925d20)
   65279 21474835991 1 GRANTED (0x4f8280e8,0x6da68a40,0x2b925d20)

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 the name of the file which is locked.

Locks are then described either as share level locks (denoted by the keyword state appearing in the line) or as byte level locks (which have a triple of addresses at the end. The fourth line in the example above is a share level lock and has the following format:

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.

The eighth line in the above example is a byte level lock. This line has the format of:

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

file control block address

tree address

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

-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 group-able 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

-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, DAFS, 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
  DAFS 0 share locks, 0 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

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
can read and write

denyR
can read, but not write

denyW
can write, but not read

denyN
can neither read not write.

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