[thirdparty/mdadm.git] / ANNOUNCE-3.0-devel1

Subject:  ANNOUNCE: mdadm 3.0-devel1 - A tool for managing Soft RAID under Linux

I am pleased to announce the availability of
   mdadm version 3.0-devel1

It is available at the usual places:
   countrycode=xx.
   http://www.${countrycode}kernel.org/pub/linux/utils/raid/mdadm/
and via git at
   git://neil.brown.name/mdadm
   http://neil.brown.name/git?p=mdadm

Note that this is a "devel" release.  It is not intended for
production use yet, but rather for testing and ongoing development.

The significant change which justifies the new major version number is
that mdadm can now handle metadata updates entirely in userspace.
This allows mdadm to support metadata formats that the kernel knows
nothing about.

Currently two such metadata formats are supported:
  - DDF  - The SNIA standard format
  - Intel Matrix - The metadata used by recent Intel ICH controlers.

The manual pages have not yet been updated, but here is a brief outline.

Externally managed metadata introduces the concept of a 'container'.
A container is a collection of (normally) physical devices which have
a common set of metadata.  A container is assembled as an md array, but
is left 'inactive'.

A container can contain one or more data arrays.  These are composed from
slices (partitions?) of various devices in the container.

For example, a 5 devices DDF set can container a RAID1 using the first
half of two devices, a RAID0 using the first half of the remain 3 devices,
and a RAID5 over thte second half of all 5 devices.

A container can be created with

   mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]

or "-e imsm" to use the Intel Matrix Storage Manager.

An array can be created within a container either by giving the
container name and the only member:

   mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0

or by listing the component devices

   mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]

The assemble a container, it is easiest just to pass each device in turn to 
mdadm -I

  for i in /dev/sd[abcde]
  do mdadm -I $i
  done

This will assemble the container and the components.

Alternately the container can be assembled explicitly

   mdadm -A /dev/md0 /dev/sd[abcde]

Then the components can all be assembled with

   mdadm -I /dev/md0

For each container, mdadm will start a program called "mdmon" which will
monitor the array and effect any metadata updates needed.  The array is
initially assembled readonly. It is up to "mdmon" to mark the metadata 
as 'dirty' and which the array to 'read-write'.

The version 0.90 and 1.x metadata formats supported by previous
versions for mdadm are still supported and the kernel still performs
the same updates it use to.  The new 'mdmon' approach is only used for
newly introduced metadata types.

Any testing and feedback will be greatly appreciated.

NeilBrown  18th September 2008
Commit	Line	Data
c04d5446 N	1	Subject: ANNOUNCE: mdadm 3.0-devel1 - A tool for managing Soft RAID under Linux
	2
	3	I am pleased to announce the availability of
	4	mdadm version 3.0-devel1
	5
	6	It is available at the usual places:
	7	countrycode=xx.
	8	http://www.${countrycode}kernel.org/pub/linux/utils/raid/mdadm/
	9	and via git at
	10	git://neil.brown.name/mdadm
	11	http://neil.brown.name/git?p=mdadm
	12
	13	Note that this is a "devel" release. It is not intended for
	14	production use yet, but rather for testing and ongoing development.
	15
	16	The significant change which justifies the new major version number is
	17	that mdadm can now handle metadata updates entirely in userspace.
	18	This allows mdadm to support metadata formats that the kernel knows
	19	nothing about.
	20
	21	Currently two such metadata formats are supported:
	22	- DDF - The SNIA standard format
	23	- Intel Matrix - The metadata used by recent Intel ICH controlers.
	24
	25	The manual pages have not yet been updated, but here is a brief outline.
	26
	27	Externally managed metadata introduces the concept of a 'container'.
	28	A container is a collection of (normally) physical devices which have
	29	a common set of metadata. A container is assembled as an md array, but
	30	is left 'inactive'.
	31
	32	A container can contain one or more data arrays. These are composed from
	33	slices (partitions?) of various devices in the container.
	34
	35	For example, a 5 devices DDF set can container a RAID1 using the first
	36	half of two devices, a RAID0 using the first half of the remain 3 devices,
	37	and a RAID5 over thte second half of all 5 devices.
	38
	39	A container can be created with
	40
	41	mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]
	42
	43	or "-e imsm" to use the Intel Matrix Storage Manager.
	44
	45	An array can be created within a container either by giving the
	46	container name and the only member:
	47
	48	mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0
	49
	50	or by listing the component devices
	51
	52	mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]
	53
	54	The assemble a container, it is easiest just to pass each device in turn to
	55	mdadm -I
	56
	57	for i in /dev/sd[abcde]
	58	do mdadm -I $i
	59	done
	60
	61	This will assemble the container and the components.
	62
	63	Alternately the container can be assembled explicitly
	64
65	mdadm -A /dev/md0 /dev/sd[abcde]
66
67	Then the components can all be assembled with
68
69	mdadm -I /dev/md0
70
71	For each container, mdadm will start a program called "mdmon" which will
72	monitor the array and effect any metadata updates needed. The array is
73	initially assembled readonly. It is up to "mdmon" to mark the metadata
74	as 'dirty' and which the array to 'read-write'.
75
76	The version 0.90 and 1.x metadata formats supported by previous
77	versions for mdadm are still supported and the kernel still performs
78	the same updates it use to. The new 'mdmon' approach is only used for
79	newly introduced metadata types.
80
81	Any testing and feedback will be greatly appreciated.
82
83	NeilBrown 18th September 2008
84