[mdadm git pull] imsm fixes and general external metadata updates

[mdadm git pull] imsm fixes and general external metadata updates

[Dan Williams]

Hi Neil,

The following changes since commit 78fbcc10312649f2f4f88283e3f19dce9b205733:
  NeilBrown (1):
        Merge branch 'master' into scratch-3.0

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/djbw/mdadm.git devel

Dan Williams (12):
      mdmon: fix missing ->subarray initialization
      imsm: fix dev_open return value handling
      imsm: imsm_read_serial check for zero-length response
      mdmon: expand permissible container device names
      mdmon: support scanning for containers
      Assemble: fix busy detection
      mdmon: make switchroot an undecorated option
      Create: allow per-metadata default layouts
      imsm: rename vprintf macro to pr_vrb
      imsm: enforce num_disks constraints
      imsm: enforce "all member disks must be members of all arrays"
      Create: warn when a metadata format's platform components are missing

 Assemble.c    |    3 +-
 Create.c      |   81 ++++++++++++++++++++++----------
 Detail.c      |    4 +-
 mdadm.h       |    4 +-
 mdmon.c       |  105 ++++++++++++++++++++++++++++-------------
 super-intel.c |  144 +++++++++++++++++++++++++++++++++++++++-----------------
 6 files changed, 234 insertions(+), 107 deletions(-)

Beyond the straightforward fixes the more interesting bits are:

mdmon: support scanning for containers
This is an attempt to make mdmon more manageable in the initramfs
environment.  Once mdadm has assembled the rootfs we need to switch the
currently running mdmon instance(s) over to the new mount point.  With
the current code it is awkward to do this in a generic way because a
script needs to know the names of all the active containers.  This tree
allows a script to do "mdmon /proc/mdstat /newroot" to batch convert all
mdmon instances to /newroot.  This is probably a good time to start
interfacing with initramfs@vger.kernel.org to make sure these "initramfs
helper" changes are relevant, and to see what else is missing.

Create: warn when a metadata format's platform components are missing
Currently if mdadm finds platform support for imsm it will block
creation of configurations that are not supported by the platform.
However if this support is not present it allows anything to be created.
This patch simply warns when mdadm cannot verify platform constraints.
The warning and verification can be silenced by setting
IMSM_NO_PLATFORM=1.

Please pull.

Thanks!
Dan

Full log:
commit 5615172f1d9daba1d5927758322f7addda803159
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:51 2009 -0700

    Create: warn when a metadata format's platform components are missing
    
    If the metadata handler can not find its platform support components
    then there is no way for it to verify that the raid configuration will
    be supported by the option-rom.  Provide a generic method for metadata
    handlers to warn the user that the array they are about to create may
    not work as intended with a given platform.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit a20d2ba5f32c76903ab6e32d83fa8c5e9c78d13f
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:51 2009 -0700

    imsm: enforce "all member disks must be members of all arrays"
    
    This is a key orom-compatibility constraint.  A nice side effect is that
    it precludes the corner case of 'create' racing against 'spare activate'
    since the create will fail to convert a spare into an array member.  At
    create time we check if this is the first member array in the container
    if it is than all disks are possible candidates, if it is not then only
    current members are permitted.
    
    A bit hairier is spare-activation handling in the presence of this
    constraint.  It is difficult because spare handling is per array.  The
    approach taken is to:
    
    1/ check that a new spare can cover all defined arrays in the container
    2/ ensure that partially assimilated spares are the first candidates
       when looking for a spare region to activate.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 1c556e92bad85ab7591ddf5ac78b90513f315b32
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    imsm: enforce num_disks constraints
    
    RAID1 == 2 disks
    RAID5 >= 3 disks
    RAID10 == 4 disks
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 35f81cbbc5ecc943c959f3c7153dcf6d83d1b994
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    imsm: rename vprintf macro to pr_vrb
    
    Don't redefine standard library calls unnecessarily...
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit a18a888ea7944aa1718e7a0daccb6f0a13b2e34d
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    Create: allow per-metadata default layouts
    
    Let handlers specify their own defaults, specifically needed for the
    imsm-raid5 case where mdadm defaults to 'ls' and imsm to 'la'.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 5746141e3f48246cd51f74562e3f947e8d0ddf6a
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    mdmon: make switchroot an undecorated option
    
    Simplify the usage from:
    	mdmon [--switch-root dir] /device/name/for/container
    to...
    	mdmon /device/name/for/container [target_dir]
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 66afdfa977d087a9cfae3175175537affd5ac6de
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    Assemble: fix busy detection
    
    Use mddev_busy() as GET_ARRAY_INFO can succeed on 'clear' arrays.
    
    Ran into this after an encountering a case where mdadm -Ss ended in
    segfault (missing check for NULL return from map_by_devnum() in
    sles11:Manage.c).  So, tried to stop the array by hand with echo clear >
    md/array_state, after which I could not reassemble since GET_ARRAY_INFO
    was succeeding.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 1ffd2840df56eab568a5744c8d8a8484a42c18e2
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    mdmon: support scanning for containers
    
    When the given container is '/proc/mdstat' then launch an mdmon instance
    per container found in /proc/mdstat.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 6f4098a6fd809acd6ef6a80051eec09f4536a27d
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:36:50 2009 -0700

    mdmon: expand permissible container device names
    
    Allow any path that dereferences to an md device to be used in addition
    to the current symbolic md device names.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 03cd4cc810fdaea1613fa6a792564aa96451f447
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 01:33:56 2009 -0700

    imsm: imsm_read_serial check for zero-length response
    
    VMWare virtual disks successfully run the inquiry but return a zero response.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit be2c0e387b88c801a5b5f07d7f447a4dba97100e
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 20 00:29:34 2009 -0700

    imsm: fix dev_open return value handling
    
    dev_open returns an fd
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit c1363b408f7b9f7a997c4cd706934a062bfca3bc
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Tue Jan 13 15:46:05 2009 -0700

    mdmon: fix missing ->subarray initialization
    
    This can cause mdmon to fail at startup.
    
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Dan Williams]

On Wed, 2009-01-21 at 15:20 -0700, Dan Williams wrote:
> Hi Neil,
> 
> The following changes since commit 78fbcc10312649f2f4f88283e3f19dce9b205733:
>   NeilBrown (1):
>         Merge branch 'master' into scratch-3.0
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/djbw/mdadm.git devel
> 

Seems you have not pulled yet, I have appended an important fix.

Thanks,
Dan

---
imsm: fix failed disks are allowed back into the container

From: Dan Williams <dan.j.williams@intel.com>

Failed disks do not have valid serial numbers which means we will not
pick up the 'failed' status bit from the metadata entry.  Check for
dl->index == -2 to prevent failed disks from being incorporated into the
container.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
 super-intel.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/super-intel.c b/super-intel.c
index 0a7c34a..5c9f413 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -1195,8 +1195,11 @@ static void getinfo_super_imsm(struct supertype *st, struct mdinfo *info)
 		info->component_size = reserved;
 		s = disk->status;
 		info->disk.state  = s & CONFIGURED_DISK ? (1 << MD_DISK_ACTIVE) : 0;
-		info->disk.state |= s & FAILED_DISK ? (1 << MD_DISK_FAULTY) : 0;
 		info->disk.state |= s & SPARE_DISK ? 0 : (1 << MD_DISK_SYNC);
+		if (s & FAILED_DISK || super->disks->index == -2) {
+			info->disk.state |= 1 << MD_DISK_FAULTY;
+			info->disk.raid_disk = -2;
+		}
 	}
 
 	/* only call uuid_from_super_imsm when this disk is part of a populated container,

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Neil Brown]

On Wednesday January 21, dan.j.williams@intel.com wrote:
> Hi Neil,
> 
> The following changes since commit 78fbcc10312649f2f4f88283e3f19dce9b205733:
>   NeilBrown (1):
>         Merge branch 'master' into scratch-3.0
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/djbw/mdadm.git devel
> 

Thanks.


> Dan Williams (12):
>       mdmon: fix missing ->subarray initialization
>       imsm: fix dev_open return value handling
>       imsm: imsm_read_serial check for zero-length response
>       mdmon: expand permissible container device names
>       mdmon: support scanning for containers
>       Assemble: fix busy detection
>       mdmon: make switchroot an undecorated option
>       Create: allow per-metadata default layouts
>       imsm: rename vprintf macro to pr_vrb
>       imsm: enforce num_disks constraints
>       imsm: enforce "all member disks must be members of all arrays"
>       Create: warn when a metadata format's platform components are missing

This all looks fine, though I confess that I didn't read "all
member disks must be members of all arrays" very closely...

> 
> Beyond the straightforward fixes the more interesting bits are:
> 
> mdmon: support scanning for containers
> This is an attempt to make mdmon more manageable in the initramfs
> environment.  Once mdadm has assembled the rootfs we need to switch the
> currently running mdmon instance(s) over to the new mount point.  With
> the current code it is awkward to do this in a generic way because a
> script needs to know the names of all the active containers.  This tree
> allows a script to do "mdmon /proc/mdstat /newroot" to batch convert all
> mdmon instances to /newroot.  This is probably a good time to start
> interfacing with initramfs@vger.kernel.org to make sure these "initramfs
> helper" changes are relevant, and to see what else is missing.

We really need a man page for mdmon don't we.  Then this sort of text
could be placed there for safely.

All pulled.

Thanks.

NeilBrown

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Mon, 2009-02-02 at 10:46 +1100, Neil Brown wrote:
> On Wednesday January 21, dan.j.williams@intel.com wrote:

> > Beyond the straightforward fixes the more interesting bits are:
> > 
> > mdmon: support scanning for containers
> > This is an attempt to make mdmon more manageable in the initramfs
> > environment.  Once mdadm has assembled the rootfs we need to switch the
> > currently running mdmon instance(s) over to the new mount point.  With
> > the current code it is awkward to do this in a generic way because a
> > script needs to know the names of all the active containers.  This tree
> > allows a script to do "mdmon /proc/mdstat /newroot" to batch convert all
> > mdmon instances to /newroot.  This is probably a good time to start
> > interfacing with initramfs@vger.kernel.org to make sure these "initramfs
> > helper" changes are relevant, and to see what else is missing.
> 
> We really need a man page for mdmon don't we.  Then this sort of text
> could be placed there for safely.

Yes, a man page is definitely needed.  I have no intention of putting
mdmon in the initramfs.  The only arrays that should be started during
initramfs operation are / and possibly /boot.  Both of those are started
readonly.  It isn't until later in the boot process (in rc.sysinit on
Fedora/RHEL) that we remount the / device rw.  It's my intention to
modify our rc.sysinit so that before the root device goes rw, we start
the necessary mdmon instances.  This should be sufficient to keep the
container metadata state consistent with reality and avoids having to
add mdmon to the initramfs.  However, that means I need to know how to
invoke mdmon when mdadm isn't starting it for me.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Dan Williams]

On Mon, Feb 23, 2009 at 8:54 AM, Doug Ledford <dledford@redhat.com> wrote:
> On Mon, 2009-02-02 at 10:46 +1100, Neil Brown wrote:
>> We really need a man page for mdmon don't we.  Then this sort of text
>> could be placed there for safely.
>
> Yes, a man page is definitely needed.

I have one brewing, I'll include it in an upcoming pull request.

> I have no intention of putting
> mdmon in the initramfs.  The only arrays that should be started during
> initramfs operation are / and possibly /boot.  Both of those are started
> readonly.  It isn't until later in the boot process (in rc.sysinit on
> Fedora/RHEL) that we remount the / device rw.  It's my intention to
> modify our rc.sysinit so that before the root device goes rw, we start
> the necessary mdmon instances.  This should be sufficient to keep the
> container metadata state consistent with reality and avoids having to
> add mdmon to the initramfs.  However, that means I need to know how to
> invoke mdmon when mdadm isn't starting it for me.

Did you happen to catch the discussion on the initramfs mailing list
[1]?  It would be nice to not need mdmon in the initramfs.  However, I
have found it needs to be there because even read-only mounted
filesystems require write access to the underlying block device to
recover the journal.

--
Dan

[1] http://thread.gmane.org/gmane.linux.kernel.initramfs/65/

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Doug Ledford]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

On Mon, 2009-02-23 at 11:58 -0700, Dan Williams wrote:
> On Mon, Feb 23, 2009 at 8:54 AM, Doug Ledford <dledford@redhat.com> wrote:
> > On Mon, 2009-02-02 at 10:46 +1100, Neil Brown wrote:
> >> We really need a man page for mdmon don't we.  Then this sort of text
> >> could be placed there for safely.
> >
> > Yes, a man page is definitely needed.
> 
> I have one brewing, I'll include it in an upcoming pull request.
> 
> > I have no intention of putting
> > mdmon in the initramfs.  The only arrays that should be started during
> > initramfs operation are / and possibly /boot.  Both of those are started
> > readonly.  It isn't until later in the boot process (in rc.sysinit on
> > Fedora/RHEL) that we remount the / device rw.  It's my intention to
> > modify our rc.sysinit so that before the root device goes rw, we start
> > the necessary mdmon instances.  This should be sufficient to keep the
> > container metadata state consistent with reality and avoids having to
> > add mdmon to the initramfs.  However, that means I need to know how to
> > invoke mdmon when mdadm isn't starting it for me.
> 
> Did you happen to catch the discussion on the initramfs mailing list
> [1]?  It would be nice to not need mdmon in the initramfs.  However, I
> have found it needs to be there because even read-only mounted
> filesystems require write access to the underlying block device to
> recover the journal.
> 
> --
> Dan
> 
> [1] http://thread.gmane.org/gmane.linux.kernel.initramfs/65/

Is XFS the only one that does the journal recovery on initial mount
read-only during the initfs step, or do other journaled fses do the same
thing?  I didn't think ext3 recovered the journal until you switch to a
read-write mount, but I guess I could be wrong.

-- 
Doug Ledford <dledford@redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [mdadm git pull] imsm fixes and general external metadata updates

[NeilBrown]

On Tue, February 24, 2009 6:53 am, Doug Ledford wrote:
> Is XFS the only one that does the journal recovery on initial mount
> read-only during the initfs step, or do other journaled fses do the same
> thing?  I didn't think ext3 recovered the journal until you switch to a
> read-write mount, but I guess I could be wrong.

This from fs/ext3/super.c

	if (EXT3_HAS_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER)) {
		if (sb->s_flags & MS_RDONLY) {
			printk(KERN_INFO "EXT3-fs: INFO: recovery "
					"required on readonly filesystem.\n");
			if (really_read_only) {
				printk(KERN_ERR "EXT3-fs: write access "
					"unavailable, cannot proceed.\n");
				return -EROFS;
			}
			printk (KERN_INFO "EXT3-fs: write access will "
					"be enabled during recovery.\n");
		}
	}

suggests that, unfortunately, you are.

NeilBrown

Re: [mdadm git pull] imsm fixes and general external metadata updates

[Luca Berra]

On Tue, Feb 24, 2009 at 07:16:06AM +1100, NeilBrown wrote:
>On Tue, February 24, 2009 6:53 am, Doug Ledford wrote:
>> Is XFS the only one that does the journal recovery on initial mount
>> read-only during the initfs step, or do other journaled fses do the same
>> thing?  I didn't think ext3 recovered the journal until you switch to a
>> read-write mount, but I guess I could be wrong.
>
>This from fs/ext3/super.c
>
>	if (EXT3_HAS_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER)) {
>		if (sb->s_flags & MS_RDONLY) {
>			printk(KERN_INFO "EXT3-fs: INFO: recovery "
>					"required on readonly filesystem.\n");
>			if (really_read_only) {
>				printk(KERN_ERR "EXT3-fs: write access "
>					"unavailable, cannot proceed.\n");
>				return -EROFS;
>			}
>			printk (KERN_INFO "EXT3-fs: write access will "
>					"be enabled during recovery.\n");
>		}
>	}
>
>suggests that, unfortunately, you are.
>
am i misreading or the above is just a check not to
incur in further problems later?

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

When read-only isn't read-only (was Re: [mdadm git pull] imsm fixes and general external metadata updates)

[John Robinson]

On 23/02/2009 20:16, NeilBrown wrote:
> On Tue, February 24, 2009 6:53 am, Doug Ledford wrote:
>> Is XFS the only one that does the journal recovery on initial mount
>> read-only during the initfs step, or do other journaled fses do the same
>> thing?  I didn't think ext3 recovered the journal until you switch to a
>> read-write mount, but I guess I could be wrong.
> 
> This from fs/ext3/super.c
> 
> 	if (EXT3_HAS_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER)) {
> 		if (sb->s_flags & MS_RDONLY) {
> 			printk(KERN_INFO "EXT3-fs: INFO: recovery "
> 					"required on readonly filesystem.\n");
> 			if (really_read_only) {
> 				printk(KERN_ERR "EXT3-fs: write access "
> 					"unavailable, cannot proceed.\n");
> 				return -EROFS;
> 			}
> 			printk (KERN_INFO "EXT3-fs: write access will "
> 					"be enabled during recovery.\n");
> 		}
> 	}
> 
> suggests that, unfortunately, you are.

Presumably it's not only me that thinks this is insane? If I want to 
mount a filesystem read-only, I expect it to be mounted read-only; 
perhaps I already know it's damaged, or know the journal's damaged...

I guess I can see the journal recovery normally being the right thing, 
and it is the filesystem we asked to have read-only not the disc, but 
still there surely has to be a way of saying mount without journal 
recovery, or mount without writing to disc, or both, and if there isn't 
who do I ask to implement it? (I'm way too rusty as a coder to trust 
myself to get it even half right.)

I wonder: in the case of ext3 can I mount it as ext2 and thereby have 
the journal ignored rather than recovered? And would this be sufficient 
for the initrd context?

Cheers,

John.

Re: When read-only isn't read-only (was Re: [mdadm git pull] imsm fixes and general external metadata updates)

[Greg Freemyer]

On Tue, Feb 24, 2009 at 6:33 PM, John Robinson
<john.robinson@anonymous.org.uk> wrote:
> On 23/02/2009 20:16, NeilBrown wrote:
>>
>> On Tue, February 24, 2009 6:53 am, Doug Ledford wrote:
>>>
>>> Is XFS the only one that does the journal recovery on initial mount
>>> read-only during the initfs step, or do other journaled fses do the same
>>> thing?  I didn't think ext3 recovered the journal until you switch to a
>>> read-write mount, but I guess I could be wrong.
>>
>> This from fs/ext3/super.c
>>
>>        if (EXT3_HAS_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER)) {
>>                if (sb->s_flags & MS_RDONLY) {
>>                        printk(KERN_INFO "EXT3-fs: INFO: recovery "
>>                                        "required on readonly
>> filesystem.\n");
>>                        if (really_read_only) {
>>                                printk(KERN_ERR "EXT3-fs: write access "
>>                                        "unavailable, cannot proceed.\n");
>>                                return -EROFS;
>>                        }
>>                        printk (KERN_INFO "EXT3-fs: write access will "
>>                                        "be enabled during recovery.\n");
>>                }
>>        }
>>
>> suggests that, unfortunately, you are.
>
> Presumably it's not only me that thinks this is insane? If I want to mount a
> filesystem read-only, I expect it to be mounted read-only; perhaps I already
> know it's damaged, or know the journal's damaged...
>
> I guess I can see the journal recovery normally being the right thing, and
> it is the filesystem we asked to have read-only not the disc, but still
> there surely has to be a way of saying mount without journal recovery, or
> mount without writing to disc, or both, and if there isn't who do I ask to
> implement it? (I'm way too rusty as a coder to trust myself to get it even
> half right.)
>
> I wonder: in the case of ext3 can I mount it as ext2 and thereby have the
> journal ignored rather than recovered? And would this be sufficient for the
> initrd context?
>
> Cheers,

I'm most familiar with xfs.  It has a norecovery flag you can use with mount.

I believe it was introduced many years ago because LVM snapshots at
the time were truly read-only and it was not possible to replay
portions of the journal in order to mount a filesystem.

I would assume all filesystems received similar enhancements?  Less
critical today because device mapper supports read/write snapshots.

Unfortunately, per the mount man page I only see that xfs has the
specific flag I'm talking about.

Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html