ANNOUNCE-3.0-devel3

   1 Subject:  ANNOUNCE: mdadm 3.0-devel3 - A tool for managing Soft RAID under Linux
   2
   3 I am pleased to announce the availability of
   4    mdadm version 3.0-devel3
   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 should be used with
  14 caution, though it is believed to be close to release-candidate stage.
  15
  16 There have been numerous improvements and additions since -devel2.
  17 I think we are close to a release of 3.0.
  18
  19 I need to add lots of tests to the test suite to test the new
  20 functionality.  And I need to review the man pages.
  21
  22 After that I will release -rc1 followed by -final.
  23
  24
  25 The following is the same introduction to 3.x as appeared in
  26 previous announcements.
  27
  28
  29 Any testing and feedback will be greatly appreciated.
  30
  31 NeilBrown  10th March 2009
  32
  33
  34 =====================================================
  35
  36 The significant change which justifies the new major version number is
  37 that mdadm can now handle metadata updates entirely in userspace.
  38 This allows mdadm to support metadata formats that the kernel knows
  39 nothing about.
  40
  41 Currently two such metadata formats are supported:
  42   - DDF  - The SNIA standard format
  43   - Intel Matrix - The metadata used by recent Intel ICH controlers.
  44
  45 Also the approach to device names has changed significantly.
  46
  47 If udev is installed on the system, mdadm will not create any devices
  48 in /dev.  Rather it allows udev to manage those devices.  For this to work
  49 as expected, the included udev rules file should be installed.
  50
  51 If udev is not install, mdadm will still create devices and symlinks
  52 as required, and will also remove them when the array is stopped.
  53
  54 mdadm now requires all devices which do not have a standard name (mdX
  55 or md_dX) to live in the directory /dev/md/.  Names in this directory
  56 will always be created as symlinks back to the standard name in /dev.
  57
  58 The man pages contain some information about the new externally managed
  59 metadata.  However see below for a more condensed overview.
  60
  61 Externally managed metadata introduces the concept of a 'container'.
  62 A container is a collection of (normally) physical devices which have
  63 a common set of metadata.  A container is assembled as an md array, but
  64 is left 'inactive'.
  65
  66 A container can contain one or more data arrays.  These are composed from
  67 slices (partitions?) of various devices in the container.
  68
  69 For example, a 5 devices DDF set can container a RAID1 using the first
  70 half of two devices, a RAID0 using the first half of the remain 3 devices,
  71 and a RAID5 over thte second half of all 5 devices.
  72
  73 A container can be created with
  74
  75    mdadm --create /dev/md0 -e ddf -n5 /dev/sd[abcde]
  76
  77 or "-e imsm" to use the Intel Matrix Storage Manager.
  78
  79 An array can be created within a container either by giving the
  80 container name and the only member:
  81
  82    mdadm -C /dev/md1 --level raid1 -n 2 /dev/md0
  83
  84 or by listing the component devices
  85
  86    mdadm -C /dev/md2 --level raid0 -n 3 /dev/sd[cde]
  87
  88 To assemble a container, it is easiest just to pass each device in turn to
  89 mdadm -I
  90
  91   for i in /dev/sd[abcde]
  92   do mdadm -I $i
  93   done
  94
  95 This will assemble the container and the components.
  96
  97 Alternately the container can be assembled explicitly
  98
  99    mdadm -A /dev/md0 /dev/sd[abcde]
 100
 101 Then the components can all be assembled with
 102
 103    mdadm -I /dev/md0
 104
 105 For each container, mdadm will start a program called "mdmon" which will
 106 monitor the array and effect any metadata updates needed.  The array is
 107 initially assembled readonly. It is up to "mdmon" to mark the metadata
 108 as 'dirty' and which the array to 'read-write'.
 109
 110 The version 0.90 and 1.x metadata formats supported by previous
 111 versions for mdadm are still supported and the kernel still performs
 112 the same updates it use to.  The new 'mdmon' approach is only used for
 113 newly introduced metadata types.