From: Stan Hoeppner <stan@hardwarefreak.com>
To: "Baldysiak, Pawel" <pawel.baldysiak@intel.com>
Cc: "neilb@suse.de" <neilb@suse.de>,
"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Problem with Raid1 when all drives failed
Date: Thu, 20 Jun 2013 04:11:13 -0500 [thread overview]
Message-ID: <51C2C731.3040906@hardwarefreak.com> (raw)
In-Reply-To: <84A53BEA6EAC69439B7E311E9B17A76F0174829C@IRSMSX105.ger.corp.intel.com>
On 6/20/2013 1:22 AM, Baldysiak, Pawel wrote:
> Hi Neil,
>
> We have observed a strange behavior of a RAID1 volume when all its drives failed.
> Here is our test case:
>
> Steps to reproduce:
> 1. Create 2-drives RAID1 (tested on both native and IMSM metadata)
> 2. Wait for the end of the initial resync
> 3. Hot-unplug both drives of the RAID1 volume
>
> Actual behavior:
> The RAID1 volume is still present in OS as a degraded one-drive array
>
> Expected behavior:
> Should a RAID volume disappear from OS?
>
> I see that when a drive is removed from OS udev runs "mdadm -If <>" for missing member which tries to write "faulty" to the state of array's member.
> I see also that md driver prevents from doing this operation for the last drive in a RAID1 array, so when two drives fail nothing really happens to the one that fails as the second one.
>
> It can be very dangerous, because if user has mounted file system at this array it can lead to unstable work of system or even a system crash. More over user does not have proper information about the state of an array.
>
> How should it work according to the design? Should mdadm stop volume when all its members disappear?
How is this scenario meaningfully different from tripping over an eSATA
cable, accidentally unplugging a JBOD chassis SAS cable, losing power to
a JBOD chassis, etc?
--
Stan
next prev parent reply other threads:[~2013-06-20 9:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 6:22 Problem with Raid1 when all drives failed Baldysiak, Pawel
2013-06-20 9:11 ` Stan Hoeppner [this message]
2013-06-24 7:08 ` NeilBrown
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=51C2C731.3040906@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=pawel.baldysiak@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.