From: Asdo <asdo@shiftmail.org>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Some md/mdadm bugs
Date: Mon, 06 Feb 2012 18:07:38 +0100 [thread overview]
Message-ID: <4F3008DA.8060402@shiftmail.org> (raw)
In-Reply-To: <4F2B1519.5010500@shiftmail.org>
On 02/02/12 23:58, Asdo wrote:
>
>>> Now it doesn't happen:
>>> When I reinserted the disk, udev triggered the --incremental, to
>>> reinsert the device, but mdadm refused to do anything because the old
>>> slot was still occupied with a failed+detached device. I manually
>>> removed the device from the raid then I ran --incremental, but mdadm
>>> still refused to re-add the device to the RAID because the array was
>>> running. I think that if it is a re-add, and especially if the
>>> bitmap is
>>> active, I can't think of a situation in which the user would *not* want
>>> to do an incremental re-add even if the array is running.
>> Hmmm.. that doesn't seem right. What version of mdadm are you running?
>
> 3.1.4
>
>> Maybe a newer one would get this right.
> I need to try...
> I think I need that.
Hi Neil,
Still some problems on mdadm 3.2.2 (from Ubuntu Precise) apparently:
Problem #1:
# mdadm -If /dev/sda4
mdadm: incremental removal requires a kernel device name, not a file:
/dev/sda4
however this works:
# mdadm -If sda4
mdadm: set sda4 faulty in md3
mdadm: hot removed sda4 from md3
Is this by design? Would your udev rule
ACTION=="remove", RUN+="/sbin/mdadm -If $name"
trigger the first or the second kind of invocation?
Problem #2:
by reinserting sda, it became sdax, and the array is still running like
this:
md3 : active raid1 sdb4[2]
10485688 blocks super 1.0 [2/1] [_U]
bitmap: 0/160 pages [0KB], 32KB chunk
please note the bitmap is active
so now I'm trying auto hot-add:
# mdadm -I /dev/sdax4
mdadm: not adding /dev/sdax4 to active array (without --run) /dev/md3
still the old problem I mentioned with 3.1.4.
Trying more ways: (even with the "--run" which is suggested)
# mdadm --run -I /dev/sdax4
mdadm: -I would set mdadm mode to "incremental", but it is already set
to "misc".
# mdadm -I --run /dev/sdax4
mdadm: failed to add /dev/sdax4 to /dev/md3: Invalid argument.
# mdadm -I --run sdax4
mdadm: stat failed for sdax4: No such file or directory.
# mdadm -I sdax4
mdadm: stat failed for sdax4: No such file or directory.
This feature not working is a problem because if one extracts one disk
by mistake, and then reinserts it, even with bitmaps active, he needs to
do a lot of manual work to re-add it to the arrays (potentially even
error-prone, if he mistakes the partition numbers)...
Thank you
A.
next prev parent reply other threads:[~2012-02-06 17:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 19:08 Some md/mdadm bugs Asdo
2012-02-02 21:17 ` NeilBrown
2012-02-02 22:58 ` Asdo
2012-02-06 16:59 ` Joel
2012-02-06 18:47 ` Asdo
2012-02-06 18:50 ` Joel
2012-02-06 17:07 ` Asdo [this message]
2012-02-06 18:47 ` Asdo
2012-02-06 22:31 ` NeilBrown
2012-02-07 17:13 ` Asdo
2012-02-09 0:55 ` NeilBrown
2012-02-06 22:20 ` NeilBrown
2012-02-07 17:47 ` Asdo
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=4F3008DA.8060402@shiftmail.org \
--to=asdo@shiftmail.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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).