Architecture - Wire Level Protocol - Revision history

Docadmin at 21:26, 22 January 2010

2010-01-22T21:26:22Z

← Older revision		Revision as of 14:26, 22 January 2010
Line 1:		Line 1:
	'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.		'''''Note:''''' ''The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.''

	== Introduction ==		== Introduction ==

Docadmin: Protected "Architecture - Wire Level Protocol" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-01-22T19:44:34Z

Protected "Architecture - Wire Level Protocol" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 12:44, 22 January 2010
(No difference)

Docadmin: /* Lustre lock request structure. */

2010-01-19T19:29:57Z

Lustre lock request structure.

← Older revision		Revision as of 12:29, 19 January 2010
Line 282:		Line 282:
	The Lustre lock manager has 3 regular calls and 2 callbacks. The regular calls are sent on the same portal as the affected service; for example, meta-data lock requests are sent to the MDS portal. The callbacks are sent to the portal reserved for DLM RPC’s. Every request to the lock manager has at least a single buffer with the ldlm_request structure as shown in table 13 in it or the ldlm_reply structure (see table 17).		The Lustre lock manager has 3 regular calls and 2 callbacks. The regular calls are sent on the same portal as the affected service; for example, meta-data lock requests are sent to the MDS portal. The callbacks are sent to the portal reserved for DLM RPC’s. Every request to the lock manager has at least a single buffer with the ldlm_request structure as shown in table 13 in it or the ldlm_reply structure (see table 17).
	===='''Lustre lock request structure.'''====		===='''Lustre lock request structure.'''====
	Any lock request in lustre consists of atleast the ldlm_request structure (see table 13).		Any lock request in lustre consists of atleast the ldlm_request structure (see table 13).

	{\| border=1 cellspacing=0		{\| border=1 cellspacing=0

Docadmin: /* Lustre lock reply structure. */

2010-01-19T19:29:43Z

Lustre lock reply structure.

← Older revision		Revision as of 12:29, 19 January 2010
Line 409:		Line 409:

	===='''Lustre lock reply structure.'''====		===='''Lustre lock reply structure.'''====
	The reply message contains a reply (see table 17).		The reply message contains a reply (see table 17).

	===='''Message structures for the various locking operations.'''====		===='''Message structures for the various locking operations.'''====
	In the following sections we will describe the message structures for the various locking operations supported in Lustre.		In the following sections we will describe the message structures for the various locking operations supported in Lustre.

Docadmin: /* LDLM_ENQUEUE. */

2010-01-19T19:29:33Z

LDLM_ENQUEUE.

← Older revision		Revision as of 12:29, 19 January 2010
Line 413:		Line 413:
	In the following sections we will describe the message structures for the various locking operations supported in Lustre.		In the following sections we will describe the message structures for the various locking operations supported in Lustre.
	===== LDLM_ENQUEUE. =====		===== LDLM_ENQUEUE. =====
	This message is used to obtain a new lock. The Lustre message contains a single buffer with a struct ldlm_request .		This message is used to obtain a new lock. The Lustre message contains a single buffer with a struct ldlm_request .

	===== LDLM_CANCEL.=====		===== LDLM_CANCEL.=====
	This message cancels an existing lock. It places a struct ldlm_request in the Lustre message, but only uses the lock_handle1 part of the request (we will shrink this in the future). The reply contains just a lustre_msg.		This message cancels an existing lock. It places a struct ldlm_request in the Lustre message, but only uses the lock_handle1 part of the request (we will shrink this in the future). The reply contains just a lustre_msg.

Docadmin: /* LDLM_CANCEL. */

2010-01-19T19:29:22Z

LDLM_CANCEL.

← Older revision		Revision as of 12:29, 19 January 2010
Line 415:		Line 415:
	This message is used to obtain a new lock. The Lustre message contains a single buffer with a struct ldlm_request .		This message is used to obtain a new lock. The Lustre message contains a single buffer with a struct ldlm_request .
	===== LDLM_CANCEL.=====		===== LDLM_CANCEL.=====
	This message cancels an existing lock. It places a struct ldlm_request in the Lustre message, but only uses the lock_handle1 part of the request (we will shrink this in the future). The reply contains just a lustre_msg.		This message cancels an existing lock. It places a struct ldlm_request in the Lustre message, but only uses the lock_handle1 part of the request (we will shrink this in the future). The reply contains just a lustre_msg.
	{\| border=1 cellspacing=0		{\| border=1 cellspacing=0
	\|-		\|-

Docadmin: /* LDLM_CONVERT */

2010-01-19T19:29:11Z

LDLM_CONVERT

← Older revision		Revision as of 12:29, 19 January 2010
Line 437:		Line 437:

	===== LDLM_CONVERT=====		===== LDLM_CONVERT=====
	This message converts the lock type of an existing lock. The request contains an ldlm request structure, as in enqueue. The requested mode field contains the mode requested after conversion. An ldlm_reply message is returned to the client.		This message converts the lock type of an existing lock. The request contains an ldlm request structure, as in enqueue. The requested mode field contains the mode requested after conversion. An ldlm_reply message is returned to the client.

	===== LDLM_BL_CALLBACK.=====		===== LDLM_BL_CALLBACK.=====
	This message is sent by the lock server to the client to indicate that a lock held by the client is blocking another lock request. This sends a struct ldlm_request with the attributes of the blocked lock in lock_desc.		This message is sent by the lock server to the client to indicate that a lock held by the client is blocking another lock request. This sends a struct ldlm_request with the attributes of the blocked lock in lock_desc.

Docadmin: /* LDLM_BL_CALLBACK. */

2010-01-19T19:28:58Z

LDLM_BL_CALLBACK.

← Older revision		Revision as of 12:28, 19 January 2010
Line 439:		Line 439:
	This message converts the lock type of an existing lock. The request contains an ldlm request structure, as in enqueue. The requested mode field contains the mode requested after conversion. An ldlm_reply message is returned to the client.		This message converts the lock type of an existing lock. The request contains an ldlm request structure, as in enqueue. The requested mode field contains the mode requested after conversion. An ldlm_reply message is returned to the client.
	===== LDLM_BL_CALLBACK.=====		===== LDLM_BL_CALLBACK.=====
	This message is sent by the lock server to the client to indicate that a lock held by the client is blocking another lock request. This sends a struct ldlm_request with the attributes of the blocked lock in lock_desc.		This message is sent by the lock server to the client to indicate that a lock held by the client is blocking another lock request. This sends a struct ldlm_request with the attributes of the blocked lock in lock_desc.

	===== LDLM_CP_CALLBACK.=====		===== LDLM_CP_CALLBACK.=====
	This message is sent by the lock server to the client to indicate that a prior unfulfilled lock request is now being granted. This too sends a struct ldlm_request with the attributes of the granted lock in lock_desc. Note that these attributes may differ from those that the client originally requested, in particular the resource name and lock mode.		This message is sent by the lock server to the client to indicate that a prior unfulfilled lock request is now being granted. This too sends a struct ldlm_request with the attributes of the granted lock in lock_desc. Note that these attributes may differ from those that the client originally requested, in particular the resource name and lock mode.

Docadmin: /* REINT_LINK. */

2010-01-19T19:28:23Z

REINT_LINK.

← Older revision		Revision as of 12:28, 19 January 2010
Line 649:		Line 649:

	==== REINT_LINK. ====		==== REINT_LINK. ====
	The link Lustre message contains 2 fields: an mds_rec_link record described in table 23 followed by a null terminated name to be used in the target directory.		The link Lustre message contains 2 fields: an mds_rec_link record described in table 23 followed by a null terminated name to be used in the target directory.
	The reply consists of an mds_body.		The reply consists of an mds_body.
	{\| border=1 cellspacing=0		{\| border=1 cellspacing=0
Line 669:		Line 669:
	\|16 \|\| lk_fid2 \|\| fid of target parent.		\|16 \|\| lk_fid2 \|\| fid of target parent.
	\|}		\|}
	TABLE 23. File link Records		TABLE 23. File link Records


	==== REINT_UNLINK.====		==== REINT_UNLINK.====

Docadmin at 00:23, 19 January 2010

2010-01-19T00:23:28Z

← Older revision		Revision as of 17:23, 18 January 2010
Line 1:		Line 1:
	'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.		'''''Note:''''' The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.


	== Introduction ==		== Introduction ==