From: Jed Davidow <jed@ultralame.com>
To: linux-raid@vger.kernel.org
Subject: Re: md rotates RAID5 spare at boot
Date: Thu, 10 Jan 2008 15:43:27 -0800 [thread overview]
Message-ID: <4786AD9F.5050400@ultralame.com> (raw)
In-Reply-To: <18310.38343.339990.718263@notabene.brown>
One quick question about those rules. The 65-mdadm rule looks like it
checks ACTIVE arrays for filesystems, and the 85 rule assembles arrays.
Shouldn't they run in the other order?
distro: Ubuntu 7.10
Two files show up...
85-mdadm.rules:
# This file causes block devices with Linux RAID (mdadm) signatures to
# automatically cause mdadm to be run.
# See udev(8) for syntax
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \
RUN+="watershed /sbin/mdadm --assemble --scan --no-degraded"
65-mdadm.vol_id.rules:
# This file causes Linux RAID (mdadm) block devices to be checked for
# further filesystems if the array is active.
# See udev(8) for syntax
SUBSYSTEM!="block", GOTO="mdadm_end"
KERNEL!="md[0-9]*", GOTO="mdadm_end"
ACTION!="add|change", GOTO="mdadm_end"
# Check array status
ATTR{md/array_state}=="|clear|inactive", GOTO="mdadm_end"
# Obtain array information
IMPORT{program}="/sbin/mdadm --detail --export $tempnode"
ENV{MD_NAME}=="?*", SYMLINK+="disk/by-id/md-name-$env{MD_NAME}"
ENV{MD_UUID}=="?*", SYMLINK+="disk/by-id/md-uuid-$env{MD_UUID}"
# by-uuid and by-label symlinks
IMPORT{program}="vol_id --export $tempnode"
OPTIONS="link_priority=-100"
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", \
SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*", \
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"
I see. So udev is invoking the assemble command as soon as it detects
the devices. So is it possible that the spare is not the last drive to
be detected and mdadm assembles too soon?
Neil Brown wrote:
> On Thursday January 10, jed@ultralame.com wrote:
>
>> It looks to me like md inspects and attempts to assemble after each
>> drive controller is scanned (from dmesg, there appears to be a failed
>> bind on the first three devices after they are scanned, and then again
>> when the second controller is scanned). Would the scan order cause a
>> spare to be swapped in?
>>
>>
>
> This suggests that "mdadm --incremental" is being used to assemble the
> arrays. Every time udev finds a new device, it gets added to
> whichever array is should be in.
> If it is called as "mdadm --incremental --run", then it will get
> started as soon as possible, even if it is degraded. With the
> "--run", it will wait until all devices are available.
>
> Even with "mdadm --incremental --run", you shouldn't get a resync if
> the last device is added before the array is written to.
>
> What distro are you running?
> What does
> grep -R mdadm /etc/udev
>
> show?
>
> NeilBrown
>
>
next prev parent reply other threads:[~2008-01-10 23:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-09 20:07 md rotates RAID5 spare at boot Jed Davidow
2008-01-10 18:03 ` Jed Davidow
2008-01-10 21:23 ` this goes go my megaraid probs too was: " Eric S. Johansson
2008-01-10 20:47 ` Bill Davidsen
2008-01-10 20:53 ` Jed Davidow
2008-01-10 22:01 ` Neil Brown
2008-01-10 23:41 ` Jed Davidow
2008-01-10 23:43 ` Jed Davidow [this message]
2008-01-11 0:24 ` Neil Brown
[not found] ` <47869D2C.7020805@ultralame.com>
2008-01-11 0:22 ` Neil Brown
2008-01-11 0:38 ` Jed Davidow
2008-01-11 1:12 ` 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=4786AD9F.5050400@ultralame.com \
--to=jed@ultralame.com \
--cc=linux-raid@vger.kernel.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).