ANNOUNCE-3.0-rc1

   1 Subject:  ANNOUNCE: mdadm 3.0-rc1 - A tool for managing Soft RAID under Linux
   2
   3 I am pleased to announce the availability of
   4    mdadm version 3.0-rc1
   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 This is a "release candidate" which means that I think it is safe
  14 to use and that there will be no significant change in functionality
  15 before release.
  16
  17 The man pages aren't really "release candidate" yet but I will be
  18 working on them before the final release.
  19
  20 The most significant changes since -devel3 relate to the names of md
  21 devices as they appear in /dev and /dev/md/, and in particular the names
  22 that are used when an array is assembled with "--incremental" or with
  23 "mdadm --assemble --scan" when there are no ARRAY lines in mdadm.conf.
  24 In these cases mdadm needs to deduce a name to use, and to try to
  25 avoid using a name that a different array might have a stronger claim to.
  26 The rules are:
  27   - if the array is mentioned in mdadm.conf, use the name given there.
  28   - if the array appear to have been created for "this host" using the
  29     "homehost" concept, trust the name given in the metadata
  30   - if the new setting "HOMEHOST <ignore>" is given (can be in mdadm.conf
  31     or on command line) the the name given in the metadata is not
  32     associated with some other array by mdadm.conf, then trust the
  33     name given in the metadata
  34   - otherwise use the name in the metadata, but in an untrusted manner.
  35
  36 If a name is untrusted, or if the name is already in use by another
  37 array, then a numeric suffix like "_0", "_1" is appended to create
  38 a unique name for the array.
  39
  40 That name is then used to create a device file in /dev/md/.
  41
  42 So if all arrays needed for boot will always be listed in
  43 /etc/mdadm.conf, then it is appropriate to add "HOMEHOST <ignore>" to
  44 mdadm.conf and there is no risk of conflicting names.  However if you
  45 want auto-assemble to assemble all arrays at boot time and you don't
  46 want to list them in mdadm.conf, then don't give "HOMEHOST <ignore>"
  47 either else there could be a risk of the wrong array being assembled
  48 for a given name.
  49
  50
  51
  52 The following is the same introduction to 3.x as appeared in
  53 previous announcements.
  54
  55 Any testing and feedback will be greatly appreciated.
  56
  57 NeilBrown  11th May 2009
  58
  59
  60 =====================================================
  61
  62 The significant change which justifies the new major version number is
  63 that mdadm can now handle metadata updates entirely in userspace.
  64 This allows mdadm to support metadata formats that the kernel knows
  65 nothing about.
  66
  67 Currently two such metadata formats are supported:
  68   - DDF  - The SNIA standard format
  69   - Intel Matrix - The metadata used by recent Intel ICH controlers.
  70
  71 Also the approach to device names has changed significantly.
  72
  73 If udev is installed on the system, mdadm will not create any devices
  74 in /dev.  Rather it allows udev to manage those devices.  For this to work
  75 as expected, the included udev rules file should be installed.
  76
  77 If udev is not install, mdadm will still create devices and symlinks
  78 as required, and will also remove them when the array is stopped.
  79
  80 mdadm now requires all devices which do not have a standard name (mdX
  81 or md_dX) to live in the directory /dev/md/.  Names in this directory
  82 will always be created as symlinks back to the standard name in /dev.
  83
  84 The man pages contain some information about the new externally managed
  85 metadata.  However see below for a more condensed overview.
  86
  87 Externally managed metadata introduces the concept of a 'container'.
  88 A container is a collection of (normally) physical devices which have
  89 a common set of metadata.  A container is assembled as an md array, but
  90 is left 'inactive'.
  91
  92 A container can contain one or more data arrays.  These are composed from
  93 slices (partitions?) of various devices in the container.
  94
  95 For example, a 5 devices DDF set can container a RAID1 using the first
  96 half of two devices, a RAID0 using the first half of the remain 3 devices,
  97 and a RAID5 over thte second half of all 5 devices.
  98
  99 A container can be created with
 100
 101    mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]
 102
 103 or "-e imsm" to use the Intel Matrix Storage Manager.
 104
 105 An array can be created within a container either by giving the
 106 container name and the only member:
 107
 108    mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0
 109
 110 or by listing the component devices
 111
 112    mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]
 113
 114 To assemble a container, it is easiest just to pass each device in turn to
 115 mdadm -I
 116
 117   for i in /dev/sd[abcde]
 118   do mdadm -I $i
 119   done
 120
 121 This will assemble the container and the components.
 122
 123 Alternately the container can be assembled explicitly
 124
 125    mdadm -A /dev/md0 /dev/sd[abcde]
 126
 127 Then the components can all be assembled with
 128
 129    mdadm -I /dev/md0
 130
 131 For each container, mdadm will start a program called "mdmon" which will
 132 monitor the array and effect any metadata updates needed.  The array is
 133 initially assembled readonly. It is up to "mdmon" to mark the metadata
 134 as 'dirty' and which the array to 'read-write'.
 135
 136 The version 0.90 and 1.x metadata formats supported by previous
 137 versions for mdadm are still supported and the kernel still performs
 138 the same updates it use to.  The new 'mdmon' approach is only used for
 139 newly introduced metadata types.