From: "Pierre Vignéras" <pierre@vigneras.name>
To: MRK <mrk@shiftmail.org>, linux-raid@vger.kernel.org
Subject: Re: mdadm: failed devices become spares!
Date: Fri, 21 May 2010 23:00:35 +0200 [thread overview]
Message-ID: <201005212300.35935.pierre@vigneras.name> (raw)
In-Reply-To: <4BF313CC.9030401@shiftmail.org>
On mercredi 19 mai 2010, MRK wrote:
> On 05/18/2010 04:06 AM, Neil Brown wrote:
> > However if --monitor gets to check the array between the above to events,
> > it will first see that the working drive is now faulty, so it reports a
> > failure, and then see that the faulty device isn't faulty any more and in
> > fact isn't even there. The "isn't event there" bit doesn't register and
> > it treats it as 'SpareActive'.
> >
> > I should fix that.
>
> However in one case the two events are not detected in the same round:
>
> Apr 12 20:10:02 phobos mdadm[3157]: Fail event detected on md device
> /dev/md2, component device /dev/sdf1
> Apr 12 20:11:02 phobos mdadm[3157]: SpareActive event detected on md device
> /dev/md2, component device /dev/sdf1
>
>
> 1 minute passes between the two entries. I suppose that's the mdadm
> daemon polling time.
>
> In the other case all the entries are at the same time
>
> Apr 13 08:00:02 phobos mdadm[3157]: Fail event detected on md device
> /dev/md2, component device /dev/sdd1
> Apr 13 08:00:02 phobos mdadm[3157]: SpareActive event detected on md device
> /dev/md2, component device /dev/sdd1
> Apr 13 08:00:02 phobos last message repeated 7 times
> [...many times that messages..]
>
>
> ...plus, in this second case the SpareActive triggers a lot of times
> within that same second (Pierre you cut it short, but are all the "many
> times that messages" all at the exact same time or they span a few
> seconds?)
Well I was probably tired when I tried to filter the log for the bug report.
It seems that this 'last message repeated 7 times' is for the:
Apr 13 08:00:02 phobos kernel: [5814019.208017] nfsd: non-standard errno: 5
not for the:
Apr 13 08:00:02 phobos mdadm[3157]: SpareActive event detected on md device
/dev/md2, component device /dev/sdd1
I looked into my log and can't find something else. Sorry, sorry, sorry if
this led you to false conclusions.
> It looks to me like some kind of usb failure where the USB connection or
> USB bridge momentarily fails then immediately gets re-detected and
> re-added to the system. But since there are no usb entries in dmesg,
> that would also be an issue of the usb driver. Could the problem also be
> a mixture with some unwise udev triggers of Debian, maybe somehow
> causing the auto-re-add of the drive to the RAID?
>
> Pierre:
> - can you post your mdadm.conf?
Sure, but I am not sure it will be useful:
$ cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=13f4fdef:db0bd815:77e02d4f:1bda00b4
ARRAY /dev/md1 level=raid1 num-devices=2
UUID=4a120782:2ed3053c:e99784b3:b8e5f7bf
ARRAY /dev/md4 level=raid1 num-devices=2
UUID=b3c7212a:e95c5081:24bf28c1:396de87f
ARRAY /dev/md2 level=raid10 num-devices=4
UUID=b34f4192:f823df58:24bf28c1:396de87f
ARRAY /dev/md3 level=raid5 num-devices=3
UUID=e1f30f82:0999431b:24bf28c1:396de87f
> - USB is not good for RAID imho. Many times in my life I saw problems
> with USB/SATA bridges where the drive would get disconnected on high I/O
> activity and then reconnected after a few seconds. Anyway, readding it
> to the RAID shouldn't have happened. Also in my case there were "usb"
> entries in dmesg.
Well, that is what I discover: USB and RAID is not currently fine (hum, on
Debian stable, not sure, we can say 'currently', kernel is:
$ uname -a
Linux phobos 2.6.26-2-686 #1 SMP Tue Mar 9 17:35:51 UTC 2010 i686 GNU/Linux
$
).
Anyway, it would be a great feature if USB can be used for a RAID setup, at
least for end users (actually, I am using in my setup, a "special" layout for
the using of RAID on several heterogeneous drives that I described here:
http://www.linuxconfig.org/prouhd-raid-for-the-end-user
)
Thanks for your help and regards.
--
Pierre Vignéras
--
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
next prev parent reply other threads:[~2010-05-21 21:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-16 15:40 mdadm: failed devices become spares! Pierre Vignéras
2010-05-16 19:56 ` Leslie Rhorer
2010-05-17 18:10 ` Pierre Vignéras
2010-05-17 21:09 ` Tim Small
2010-05-18 1:30 ` Neil Brown
2010-05-18 2:06 ` Neil Brown
2010-05-18 22:25 ` MRK
2010-05-19 19:56 ` Simon Matthews
2010-05-21 21:00 ` Pierre Vignéras [this message]
2010-05-21 21:27 ` mdadm: failed devices become spares! -> Solved ! Pierre Vignéras
2010-05-18 23:07 ` mdadm: failed devices become spares! Pierre Vignéras
2010-05-19 1:45 ` Neil Brown
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=201005212300.35935.pierre@vigneras.name \
--to=pierre@vigneras.name \
--cc=linux-raid@vger.kernel.org \
--cc=mrk@shiftmail.org \
/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).