linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: linux-raid@vger.kernel.org
Subject: Subject:  ANNOUNCE: mdadm 3.2 - A tool for managing Soft RAID under Linux (DEVEL ONLY)
Date: Tue, 1 Feb 2011 16:12:58 +1100	[thread overview]
Message-ID: <20110201161258.0dab6473@notabene.brown> (raw)


I am pleased to announce the availability of
   mdadm version 3.2

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 devel-3.2
   http://neil.brown.name/git?p=mdadm

This is a "Developers only" release.  Please don't consider using it
or making it available to others without reading the following.


By far the most significant change in this release related to the
management of reshaping arrays.  This code has been substantially
re-written so that it can work with 'externally managed metadata' -
Intel's IMSM in particular.  We now support level migration and
OnLine Capacity Expansion on these arrays.

However, while the code largely works it has not been tested
exhaustively so there are likely to be problems.  As the reshape code
for native metadata arrays was changed as part of this rewrite these
problems could also result in regressions for reshape of native
metadata.

It is partly to encourage greater testing that this release is being
made.  Any reports of problem - particular reproducible recipes for
triggering the problems - will be gratefully received.

It is hopped that a "3.2.1" release will be available in early March
which will be a bugfix release over this and can be considered
suitable for general use.

Other changes of note:

 - Policy framework.
   Various policy statements can be made in the mdadm.conf to guide
   the behaviour of mdadm, particular with regards to how new devices
   are treated by "mdadm -I".
   Depending on the 'action' associated with a device (identified by
   its 'path') such need devices can be automatically re-added to and
   existing array that they previously fell out off, or automatically
   added as a spare if they appear to contain no data.

 - mdadm now has a limited understanding of partition tables.  This
   allows the policy framework to make decisions about partitioned
   devices as well.

 - --incremental --remove can be told what --path the device was on,
   and this info will be recorded so that another device appearing at
   the same physical location can be preferentially added to the same
   array (provides the spare-same-slot action policy applied to the
   path).

 - A new flags "--invalid-backup" flag is available in --assemble
   mode.  This can be used to re-assemble an array which was stopping
   in the middle of a reshape, and for which the 'backup file' is no
   longer available or is corrupted.  The array may have some
   corruption in it at the point where reshape was up to, but at least
   the rest of the array will become available.
   

 - Various internal restructuring - more is needed.


Any feed back and bug reports are always welcomed at:
    linux-raid@vger.kernel.org

And please:  don't use this in production - particularly not the
--grow functionality.

NeilBrown 1st February 2011



                 reply	other threads:[~2011-02-01  5:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110201161258.0dab6473@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).