--- /dev/null
+
+
+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
return _sys_dev_type[type];
}
-#ifndef MDASSEMBLE
static struct intel_hba * alloc_intel_hba(struct sys_dev *device)
{
struct intel_hba *result = malloc(sizeof(*result));
return result;
}
-
static int attach_hba_to_super(struct intel_super *super, struct sys_dev *device)
{
struct intel_hba *hba;
return NULL;
}
-#endif /* MDASSEMBLE */
static int find_intel_hba_capability(int fd, struct intel_super *super,
*/
chunk = __le16_to_cpu(map->blocks_per_strip) >> 1;
+#ifndef MDASSEMBLE
if (!validate_geometry_imsm_orom(super,
get_imsm_raid_level(map), /* RAID level */
imsm_level_to_layout(get_imsm_raid_level(map)),
"Cannot proceed with the action(s).\n");
continue;
}
+#endif /* MDASSEMBLE */
this = malloc(sizeof(*this));
if (!this) {
fprintf(stderr, Name ": failed to allocate %zu bytes\n",