Clustered Metadata - Revision history

Sbarthel at 18:36, 10 September 2010

2010-09-10T18:36:54Z

← Older revision		Revision as of 11:36, 10 September 2010
Line 1:		Line 1:
	<small>''(Updated: ~~Jan~~ 2010)''</small>		<small>''(Updated: Sep 2010)''</small>
	__TOC__		__TOC__
	This document describes the design of the clustered metadata handling		This document describes the design of the clustered metadata handling

2010-09-05T13:38:37Z

Recovery: mention epochs at the end instead of the beginning

← Older revision		Revision as of 06:38, 5 September 2010
Line 80:		Line 80:
	== Recovery ==		== Recovery ==

	~~In the long term~~, ~~CMD recovery will rely on global epochs, which will not be implemented in the initial version. Instead, those~~ metadata operations that span multiple MDSs (MDTs) will be synchronous to simplify recovery from a system crash. This may impact the performance of operations involving several MDTs. Also, ~~a small amount of memory~~ leak may occur after MDS recovery.		Initially, metadata operations that span multiple MDSs (MDTs) will be ordered and synchronous to simplify recovery from a system crash. This may impact the performance of operations involving several MDTs. Also, an inode leak may occur after MDS recovery, but only in such a way that data is never lost. These leaked inodes will be deleted by lfsck verification of the MDT filesystems.

			In the long term, CMD recovery will rely on global epochs, which will allow distributed asynchronous updates to multiple MDTs.

	== Locking ==		== Locking ==

	We believe locking can be done in ''fid'' order as it is currently done on the MDS.		We believe locking can be done in ''fid'' order as it is currently done on the MDS.

2010-02-22T13:40:21Z

← Older revision		Revision as of 06:40, 22 February 2010
Line 1:		Line 1:
	''(Updated: Jan 2010)''		<small>''(Updated: Jan 2010)''</small>

	__TOC__		__TOC__
	This document describes the design of the clustered metadata handling		This document describes the design of the clustered metadata handling

2010-02-22T04:49:03Z

← Older revision		Revision as of 21:49, 21 February 2010
Line 1:		Line 1:
			''(Updated: Jan 2010)''

	__TOC__		__TOC__
	This document describes the design of the clustered metadata handling		This document describes the design of the clustered metadata handling
Line 84:		Line 86:

	We believe locking can be done in ''fid'' order as it is currently done on the MDS.		We believe locking can be done in ''fid'' order as it is currently done on the MDS.

	~~''(Updated 1/10)''~~

2010-02-10T02:44:55Z

Locking

← Older revision		Revision as of 19:44, 9 February 2010
Line 84:		Line 84:

	We believe locking can be done in ''fid'' order as it is currently done on the MDS.		We believe locking can be done in ''fid'' order as it is currently done on the MDS.

			''(Updated 1/10)''

2010-01-14T21:01:07Z

1 revision

← Older revision	Revision as of 14:01, 14 January 2010
(No difference)

2010-01-11T19:38:38Z

MDS implementation

← Older revision		Revision as of 12:38, 11 January 2010
Line 70:		Line 70:
	* ''mkdir'' always creates the new directory on another MDS.		* ''mkdir'' always creates the new directory on another MDS.
	* ''unlink'', ''rmdir'', and ''rename'' may involve more than one MDS.		* ''unlink'', ''rmdir'', and ''rename'' may involve more than one MDS.
	* For ''large directories'', all operations making updates to directories can cause a directory split~~. The directory split is discussed below~~.		* For ''large directories'', all operations making updates to directories can cause a [[#Directory_Split\|directory split]].
	* For ''other operations'', [[if no splits large directories~~]] '''[[Is a word missing here?]]'''~~ are encountered, all other operations proceed as they are executed on one MDS.		* For ''other operations'', if no splits in large directories are encountered, all other operations proceed as they are executed on one MDS.

	=== Directory Split ===		=== Directory Split ===

2010-01-11T19:35:46Z

Recovery

← Older revision		Revision as of 12:35, 11 January 2010
Line 79:		Line 79:
	== Recovery ==		== Recovery ==

	In the long term, CMD recovery will rely on global epochs, which will not be implemented in the initial version. Instead, those metadata operations that span multiple MDSs (MDTs) will be synchronous [[to ~~avoid~~ recovery ~~once the~~ system crash]]. This may impact the performance of operations involving several MDTs. Also, a small amount of memory leak may occur after MDS recovery.		In the long term, CMD recovery will rely on global epochs, which will not be implemented in the initial version. Instead, those metadata operations that span multiple MDSs (MDTs) will be synchronous to simplify recovery from a system crash. This may impact the performance of operations involving several MDTs. Also, a small amount of memory leak may occur after MDS recovery.

	== Locking ==		== Locking ==

	We believe locking can be done in ''fid'' order as it is currently done on the MDS.		We believe locking can be done in ''fid'' order as it is currently done on the MDS.

2010-01-11T18:17:09Z

Recovery

@@ Line 79: / Line 79: @@
 == Recovery ==
-=== Transaction Replay ===
+In the long term, CMD recovery will rely on global epochs, which will not be implemented in the initial version. Instead, those metadata operations that span multiple MDSs (MDTs) will be synchronous [[to avoid recovery once the system crash]]. This may impact the performance of operations involving several MDTs. Also, a small amount of memory leak may occur after MDS recovery.
 == Locking ==
 We believe locking can be done in ''fid'' order as it is currently done on the MDS.

2010-01-11T17:44:33Z

Directory Split

← Older revision		Revision as of 10:44, 11 January 2010
Line 75:		Line 75:
	=== Directory Split ===		=== Directory Split ===

	A directory ~~that is growing larger will~~ be ~~split~~. ~~A fairly heavy penalty is associated with splitting~~ the directory ~~and also with renames within~~ split ~~directories. Moreover, at the point of splitting, inodes become remote~~ and will ~~incur a penalty upon ''unlink''~~.		A directory can be striped over several MDTs as files over several OSTs. Then the directory will be split into several objects and each one will be located in different MDTs. The layout information(stripe EA) will be stored in the extend attributes of all split objects.

	~~Probably it is best to delay~~ the split ~~until the directory is fairly large, and then to split over several nodes to avoid further splits being necessary soon afterward~~.

	== Recovery ==		== Recovery ==