[thirdparty/mdadm.git] / ANNOUNCE-3.2.1



I am pleased to announce the availability of
   mdadm version 3.2.1

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/mdadm

Many of the changes in this release are of internal interest only,
restructuring and refactoring code and so forth.

Most of the bugs found and fixed during development for 3.2.1 have been
back-ported for the recently-release 3.1.5 so this release primarily
provides a few new features over 3.1.5.

They include:
  - policy framework
     Policy can be expressed for moving spare devices between arrays, and
     for how to handle hot-plugged devices.  This policy can be different
     for devices plugged in to different controllers etc.
     This, for example, allows a configuration where when a device is plugged
     in it is immediately included in an md array as a hot spare and
     possibly starts recovery immediately if an array is degraded.

  - some understanding of mbr and gpt paritition tables
     This is primarly to support the new hot-plug support.  If a
     device is plugged in and policy suggests it should have a partition table,
     the partition table will be copied from a suitably similar device, and
     then the partitions will hot-plug and can then be added to md arrays.

  - "--incremental --remove" can remember where a device was removed from
    so if a device gets plugged back in the same place, special policy applies
    to it, allowing it to be included in an array even if a general hotplug
    will not be included.

  - enhanced reshape options, including growing a RAID0 by converting to RAID4,
    restriping, and converting back.  Also convertions between RAID0 and
    RAID10 and between RAID1 and RAID10 are possible (with a suitably recent
    kernel).

  - spare migration for IMSM arrays.
     Spare migration can now work across 'containers' using non-native metadata
     and specifically Intel's IMSM arrays support spare migrations.

  - OLCE and level migration for Intel IMSM arrays.
     OnLine Capacity Expansion and level migration (e.g. RAID0 -> RAID5) is
     supported for Intel Matrix Storage Manager arrays.
     This support is currently 'experimental' for technical reasons.  It can
     be enabled with "export MDADM_EXPERIMENTAL=1"

  - avoid including wayward devices
     If you split a RAID1, mount the two halves as two separate degraded RAID1s,
     and then later bring the two back together, it is possible that the md 
     metadata won't properly show that one must over-ride the other.
     mdadm now does extra checking to detect this possibilty and avoid
     potentially corrupting data.

  - remove any possible confusion between similar options.
     e.g. --brief and --bitmap were mapped to 'b' and mdadm wouldn't
     notice if one was used where the other was expected.

  - allow K,M,G suffixes on chunk sizes


While mdadm-3.2.1 is considered to be reasonably stable, you should
only use it if you want to try out the new features, or if you
generally like to be on the bleeding edge.   If the new features are not
important to you, then 3.1.5 is probably the appropriate version to be using
until 3.2.2 comes out.

NeilBrown 28th March 2011
Commit	Line	Data
7b0bbd0f N	1
	2
	3	I am pleased to announce the availability of
	4	mdadm version 3.2.1
	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/mdadm
	12
	13	Many of the changes in this release are of internal interest only,
	14	restructuring and refactoring code and so forth.
	15
	16	Most of the bugs found and fixed during development for 3.2.1 have been
	17	back-ported for the recently-release 3.1.5 so this release primarily
	18	provides a few new features over 3.1.5.
	19
	20	They include:
	21	- policy framework
	22	Policy can be expressed for moving spare devices between arrays, and
	23	for how to handle hot-plugged devices. This policy can be different
	24	for devices plugged in to different controllers etc.
	25	This, for example, allows a configuration where when a device is plugged
	26	in it is immediately included in an md array as a hot spare and
	27	possibly starts recovery immediately if an array is degraded.
	28
	29	- some understanding of mbr and gpt paritition tables
	30	This is primarly to support the new hot-plug support. If a
	31	device is plugged in and policy suggests it should have a partition table,
	32	the partition table will be copied from a suitably similar device, and
	33	then the partitions will hot-plug and can then be added to md arrays.
	34
	35	- "--incremental --remove" can remember where a device was removed from
	36	so if a device gets plugged back in the same place, special policy applies
	37	to it, allowing it to be included in an array even if a general hotplug
	38	will not be included.
	39
	40	- enhanced reshape options, including growing a RAID0 by converting to RAID4,
	41	restriping, and converting back. Also convertions between RAID0 and
	42	RAID10 and between RAID1 and RAID10 are possible (with a suitably recent
	43	kernel).
	44
	45	- spare migration for IMSM arrays.
	46	Spare migration can now work across 'containers' using non-native metadata
	47	and specifically Intel's IMSM arrays support spare migrations.
	48
	49	- OLCE and level migration for Intel IMSM arrays.
	50	OnLine Capacity Expansion and level migration (e.g. RAID0 -> RAID5) is
	51	supported for Intel Matrix Storage Manager arrays.
	52	This support is currently 'experimental' for technical reasons. It can
	53	be enabled with "export MDADM_EXPERIMENTAL=1"
	54
	55	- avoid including wayward devices
	56	If you split a RAID1, mount the two halves as two separate degraded RAID1s,
	57	and then later bring the two back together, it is possible that the md
	58	metadata won't properly show that one must over-ride the other.
	59	mdadm now does extra checking to detect this possibilty and avoid
	60	potentially corrupting data.
	61
	62	- remove any possible confusion between similar options.
	63	e.g. --brief and --bitmap were mapped to 'b' and mdadm wouldn't
	64	notice if one was used where the other was expected.
65
66	- allow K,M,G suffixes on chunk sizes
67
68
69	While mdadm-3.2.1 is considered to be reasonably stable, you should
70	only use it if you want to try out the new features, or if you
71	generally like to be on the bleeding edge. If the new features are not
72	important to you, then 3.1.5 is probably the appropriate version to be using
73	until 3.2.2 comes out.
74
75	NeilBrown 28th March 2011