Logging API - Revision history

Sbarthel at 17:17, 22 February 2010

2010-02-22T17:17:05Z

← Older revision		Revision as of 10:17, 22 February 2010
Line 1:		Line 1:
			<small>''(Updated: Dec 2009)''</small>
	__TOC__		__TOC__
	In numerous places Lustre™ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.		In numerous places Lustre™ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.

Docadmin at 20:23, 17 December 2009

2009-12-17T20:23:37Z

← Older revision		Revision as of 13:23, 17 December 2009
Line 1:		Line 1:
			__TOC__
	In numerous places Lustre™ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.		In numerous places Lustre™ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.

Docadmin: Protected "Logging API" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2009-12-16T18:26:03Z

Protected "Logging API" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 11:26, 16 December 2009
(No difference)

Docadmin at 18:25, 16 December 2009

2009-12-16T18:25:51Z

← Older revision		Revision as of 11:25, 16 December 2009
Line 1:		Line 1:
	In numerous places ~~Lustre~~ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.		In numerous places Lustre™ needs a logging API. Generally log records are written transactionally and canceled when a commit on another system completes. There are many uses for this, all associated with updates of persistent information on multiple systems.

	Log records are stored in log objects. Log objects are currently implemented as files, and possibly, in some minor ways, the API below reflects this. We speak of log objects and sometimes of llog's (''lustre-logs'').		Log records are stored in log objects. Log objects are currently implemented as files, and possibly, in some minor ways, the API below reflects this. We speak of log objects and sometimes of llog's (''lustre-logs'').

Docadmin: moved Logging Api to Logging API

2009-12-09T17:45:53Z

moved Logging Api to Logging API

← Older revision	Revision as of 10:45, 9 December 2009
(No difference)

Docadmin: /* Fundamental Data Structures */

2009-12-09T17:22:20Z

Fundamental Data Structures

← Older revision		Revision as of 10:22, 9 December 2009
Line 39:		Line 39:

	A catalog API is provided which exploits the lower Lustre log API.		A catalog API is provided which exploits the lower Lustre log API.
	* Catalog entries contain an llog_cookie which references another llog object		* Catalog entries contain an ''llog_cookie'' which references another ''llog'' object

	= Cancellation API =		= Cancellation API =

Adilger: /* Log API's */ improve readability, add some descriptions

2009-12-09T04:51:55Z

Log API's: improve readability, add some descriptions

← Older revision		Revision as of 21:51, 8 December 2009
Line 187:		Line 187:
	</pre>		</pre>

	== Higher Level Log Operations ==		==== Higher Level Log Operations ====
	~~[[Is this a higher-level log operation example?]]~~

	* Initialize the handle. Try to read it from the log file, but if the log has no header yet, build it from the arguments. If the header is read, verify the flags and UUID in the log equal those of the arguments.		* Initialize the handle. Try to read it from the log file, but if the log has no header yet, build it from the arguments. If the header is read, verify the flags and UUID in the log equal those of the arguments.
Line 196:		Line 195:
	</pre>		</pre>

	== OBD Level Log Operations ==		==== OBD Level Log Operations ====

	~~[[Are these OBD-level examples? What do they do?]]~~

			* Add the record with header ''rec'' and data ''buf'' to the llog ''loghandle'' and return the llog_cookie(s) in ''logcookies''
	<pre>		<pre>
	int llog_add_record(struct llog_handle ~~cathandle~~, struct llog_trans_hdr rec,		int llog_add_record(struct llog_handle loghandle, struct llog_trans_hdr rec,
	struct llog_cookie logcookies, void buf)		struct llog_cookie logcookies, void buf)
	</pre>		</pre>

	<pre>		<pre>
	int llog_delete_log(struct llog_handle ~~cathandle~~,struct llog_handle loghandle)		int llog_delete_log(struct llog_handle loghandle, struct llog_handle loghandle)
	~~</pre>~~

	~~<pre>~~
	~~int llog_cancel_records(struct llog_handle cathandle, int count, struct llog_cookie cookies~~)
	</pre>		</pre>

	For each cookie in the cookie array, we clear the log in-use bit and either:		For each cookie in the cookie array, we clear the log in-use bit and either:
			* The log is not empty, just write out the log header
	* The log is empty, so mark it free in the catalog header and delete it		* The log is empty, so mark it free in the catalog header and delete it
	* The log is not empty, just write out the log header

	The cookies may be in different log files, so we need to get new logs each time.		The cookies may be in different log files, so we need to get new logs each time.

			<pre>
			int llog_cancel_records(struct llog_handle loghandle, int count, struct llog_cookie cookies)
			</pre>

	~~[[Are these OBD-level examples?]]~~		==== Log processing ====

	* Return the block in the log that contains record with index ''next_idx''. The current ''idx'' at offset ''cur_offset'' is used to optimize the search.		* Return the block in the log that contains record with index ''next_idx''. The current ''idx'' at offset ''cur_offset'' is used to optimize the search.
Line 228:		Line 225:
	</pre>		</pre>

	* ~~Call~~ the callback function ''cb''.		* For each valid record in the log referenced by ''loghandle'' call the callback function ''cb'', and pass it the current record ''rec'' and the caller opaque data ''data''.

	:<pre>		:<pre>

Adilger: /* Low Level Log Operations */

2009-12-09T04:44:49Z

Low Level Log Operations

← Older revision		Revision as of 21:44, 8 December 2009
Line 147:		Line 147:
	Log operations are described in this section.		Log operations are described in this section.

	=== Low Level Log Operations ===		==== Low Level Log Operations ====

	Logs can be opened and/or created. This fills in a log handle. The log handle can be used through the log handle API. Some low-level log operations with examples are shown below:		Logs can be opened and/or created. This fills in a log handle. The log handle can be used through the log handle API. Some low-level log operations with examples are shown below:

Adilger: /* Low Level Log Operations */

2009-12-09T04:44:06Z

Low Level Log Operations

← Older revision		Revision as of 21:44, 8 December 2009
Line 147:		Line 147:
	Log operations are described in this section.		Log operations are described in this section.

	== Low Level Log Operations ==		=== Low Level Log Operations ===

	Logs can be opened and/or created. This fills in a log handle. The log handle can be used through the log handle API. Some low-level log operations with examples are shown below:		Logs can be opened and/or created. This fills in a log handle. The log handle can be used through the log handle API. Some low-level log operations with examples are shown below:

Adilger: /* Server Network Striping (Mirrored objects) */

2009-12-09T04:42:32Z

Server Network Striping (Mirrored objects)

← Older revision		Revision as of 21:42, 8 December 2009
Line 102:		Line 102:


	==== Server Network Striping (Mirrored objects) ===		==== Server Network Striping (Mirrored objects) ====
	* The primary is the originator, the secondary the replica		* The primary is the originator, the secondary the replica
	* Writes on the primary are accompanied by a change record for an extent		* Writes on the primary are accompanied by a change record for an extent