From: NeilBrown <neilb@suse.de>
To: "Baldysiak, Pawel" <pawel.baldysiak@intel.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Problem with Raid1 when all drives failed
Date: Mon, 24 Jun 2013 17:08:24 +1000 [thread overview]
Message-ID: <20130624170824.39dc8d99@notabene.brown> (raw)
In-Reply-To: <84A53BEA6EAC69439B7E311E9B17A76F0174829C@IRSMSX105.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
On Thu, 20 Jun 2013 06:22:32 +0000 "Baldysiak, Pawel"
<pawel.baldysiak@intel.com> 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
That is what I expect.
>
> Expected behavior:
> Should a RAID volume disappear from OS?
How exactly? If the filesystem is mounted that would be impossible.
>
> 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.
It shouldn't lead to a crash. But it could certainly cause problems.
Unplugged active devices often does.
>
> How should it work according to the design? Should mdadm stop volume when all its members disappear?
Have a look at the current code in my "master" branch. When this happens it
will try to stop the array (which will fail if the array is mounted), and
will try to get "udisks" to unmount the array (which will fail if the
filesytem is in use).
So it goes a little way in the direction you want, but I think that what you
are asking for is impossible with Linux.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
prev parent reply other threads:[~2013-06-24 7:08 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
2013-06-24 7:08 ` NeilBrown [this message]
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=20130624170824.39dc8d99@notabene.brown \
--to=neilb@suse.de \
--cc=linux-raid@vger.kernel.org \
--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 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).