All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: "Guilherme G. Piccoli" <gpiccoli@canonical.com>,
	Jes Sorensen <jes.sorensen@gmail.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"liu.song.a23@gmail.com" <liu.song.a23@gmail.com>,
	NeilBrown <neilb@suse.com>,
	linux-raid <linux-raid@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"jay.vosburgh@canonical.com" <jay.vosburgh@canonical.com>
Subject: Re: [PATCH v3 2/2] mdadm: Introduce new array state 'broken' for raid0/linear
Date: Thu, 22 Aug 2019 21:56:17 +0000	[thread overview]
Message-ID: <060E4BAF-E16D-4ADF-AE93-39097DB739DD@fb.com> (raw)
In-Reply-To: <20190822161318.26236-2-gpiccoli@canonical.com>



> On Aug 22, 2019, at 9:13 AM, Guilherme G. Piccoli <gpiccoli@canonical.com> wrote:
> 
> Currently if a md raid0/linear array gets one or more members removed while
> being mounted, kernel keeps showing state 'clean' in the 'array_state'
> sysfs attribute. Despite udev signaling the member device is gone, 'mdadm'
> cannot issue the STOP_ARRAY ioctl successfully, given the array is mounted.
> 
> Nothing else hints that something is wrong (except that the removed devices
> don't show properly in the output of mdadm 'detail' command). There is no
> other property to be checked, and if user is not performing reads/writes
> to the array, even kernel log is quiet and doesn't give a clue about the
> missing member.
> 
> This patch is the mdadm counterpart of kernel new array state 'broken'.
> The 'broken' state mimics the state 'clean' in every aspect, being useful
> only to distinguish if an array has some member missing. All necessary
> paths in mdadm were changed to deal with 'broken' state, and in case the
> tool runs in a kernel that is not updated, it'll work normally, i.e., it
> doesn't require the 'broken' state in order to work.
> Also, this patch changes the way the array state is showed in the 'detail'
> command (for raid0/linear only) - now it takes the 'array_state' sysfs
> attribute into account instead of only rely in the MD_SB_CLEAN flag.
> 
> Cc: NeilBrown <neilb@suse.com>
> Cc: Song Liu <songliubraving@fb.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>

CC Jes, who maintains mdadm. 

WARNING: multiple messages have this Message-ID (diff)
From: Song Liu <songliubraving@fb.com>
To: "Guilherme G. Piccoli" <gpiccoli@canonical.com>,
	Jes Sorensen <jes.sorensen@gmail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"jay.vosburgh@canonical.com" <jay.vosburgh@canonical.com>,
	"liu.song.a23@gmail.com" <liu.song.a23@gmail.com>,
	NeilBrown <neilb@suse.com>
Subject: Re: [PATCH v3 2/2] mdadm: Introduce new array state 'broken' for raid0/linear
Date: Thu, 22 Aug 2019 21:56:17 +0000	[thread overview]
Message-ID: <060E4BAF-E16D-4ADF-AE93-39097DB739DD@fb.com> (raw)
In-Reply-To: <20190822161318.26236-2-gpiccoli@canonical.com>



> On Aug 22, 2019, at 9:13 AM, Guilherme G. Piccoli <gpiccoli@canonical.com> wrote:
> 
> Currently if a md raid0/linear array gets one or more members removed while
> being mounted, kernel keeps showing state 'clean' in the 'array_state'
> sysfs attribute. Despite udev signaling the member device is gone, 'mdadm'
> cannot issue the STOP_ARRAY ioctl successfully, given the array is mounted.
> 
> Nothing else hints that something is wrong (except that the removed devices
> don't show properly in the output of mdadm 'detail' command). There is no
> other property to be checked, and if user is not performing reads/writes
> to the array, even kernel log is quiet and doesn't give a clue about the
> missing member.
> 
> This patch is the mdadm counterpart of kernel new array state 'broken'.
> The 'broken' state mimics the state 'clean' in every aspect, being useful
> only to distinguish if an array has some member missing. All necessary
> paths in mdadm were changed to deal with 'broken' state, and in case the
> tool runs in a kernel that is not updated, it'll work normally, i.e., it
> doesn't require the 'broken' state in order to work.
> Also, this patch changes the way the array state is showed in the 'detail'
> command (for raid0/linear only) - now it takes the 'array_state' sysfs
> attribute into account instead of only rely in the MD_SB_CLEAN flag.
> 
> Cc: NeilBrown <neilb@suse.com>
> Cc: Song Liu <songliubraving@fb.com>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>

CC Jes, who maintains mdadm. 


  reply	other threads:[~2019-08-22 21:56 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 16:13 [PATCH v3 1/2] md raid0/linear: Mark array as 'broken' and fail BIOs if a member is gone Guilherme G. Piccoli
2019-08-22 16:13 ` Guilherme G. Piccoli
2019-08-22 16:13 ` [PATCH v3 2/2] mdadm: Introduce new array state 'broken' for raid0/linear Guilherme G. Piccoli
2019-08-22 16:13   ` Guilherme G. Piccoli
2019-08-22 21:56   ` Song Liu [this message]
2019-08-22 21:56     ` Song Liu
2019-08-29 12:51   ` Guilherme G. Piccoli
2019-08-29 12:51     ` Guilherme G. Piccoli
2019-08-30  8:17   ` NeilBrown
2019-08-30  8:17     ` NeilBrown
2019-08-30 12:48     ` Guilherme G. Piccoli
2019-08-30 12:48       ` Guilherme G. Piccoli
2019-08-22 21:55 ` [PATCH v3 1/2] md raid0/linear: Mark array as 'broken' and fail BIOs if a member is gone Song Liu
2019-08-22 21:55   ` Song Liu
2019-08-23 17:48   ` Guilherme G. Piccoli
2019-08-23 17:48     ` Guilherme G. Piccoli
2019-08-23 17:51     ` Song Liu
2019-08-23 17:51       ` Song Liu
2019-08-30 10:47       ` Wols Lists
2019-08-30 10:47         ` Wols Lists
2019-08-30 11:25         ` Guilherme Piccoli
2019-08-30 11:25           ` Guilherme Piccoli
2019-09-03 19:53           ` Guilherme G. Piccoli
2019-09-03 19:53             ` Guilherme G. Piccoli
2019-08-30  8:08 ` NeilBrown
2019-08-30  8: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=060E4BAF-E16D-4ADF-AE93-39097DB739DD@fb.com \
    --to=songliubraving@fb.com \
    --cc=dm-devel@redhat.com \
    --cc=gpiccoli@canonical.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=jes.sorensen@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=liu.song.a23@gmail.com \
    --cc=neilb@suse.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.