linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Soltys <soltys@ziu.info>
To: nterry <nigel@nigelterry.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: Raid 5 Problem
Date: Sun, 14 Dec 2008 23:02:46 +0100	[thread overview]
Message-ID: <49458286.7060802@ziu.info> (raw)
In-Reply-To: <49457BE3.4090200@nigelterry.net>

nterry wrote:
> [root@homepc ~]# mdadm -Esvv /dev/sdb
> /dev/sdb:
>          Magic : a92b4efc
>        Version : 0.90.02
>           UUID : c57d50aa:1b3bcabd:ab04d342:6049b3f1
>  Creation Time : Thu Dec 15 15:29:36 2005
>     Raid Level : raid5

Yup - that's leftover block from one of your earlier arrays/attempts. It 
just happens to sit in unused area of /dev/sdb1, but is picked as valid 
/dev/sdb superblock

> 
> I added the DEVICE /dev/sd[bcde]1 to mdadm.conf and that apepars to have 
> fixed the problem.  2 reboots and it worked both times.
> 
> I also note now that:
> [root@homepc ~]# mdadm --examine --scan
> ARRAY /dev/md0 level=raid5 num-devices=4 
> UUID=50e3173e:b5d2bdb6:7db3576b:644409bb
>   spares=1
> [root@homepc ~]#

That DEVICE line limits mdadm to only look at sd[bcde]1 as potential 
array members, so examine shows only current array. If you plan to add 
more raid arrays later, be sure to change it. Also read below.

> Frankly I don't know enough about the workings of udev and the boot 
> process to be able to get into that.  However these two files might mean 
> something to you:
> 
> [...]
> 
> AND...
> 
> [root@homepc ~]# cat /etc/udev/rules.d/70-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+="/sbin/mdadm -I --auto=yes $root/%k"
> [root@homepc ~]#
> 

That's the part of the problem. In human language it means, that during 
udev event related to device add or change, any device detected as being 
part of linux raid, will be incrementally assembled. ID_FS_TYPE is 
exported in one of the earlier rules by vol_id helper tool. So during 
initial udev run, /dev/sdb is picked up, and forces mdadm later to drop 
/dev/sdb1 from array during every boot.

You can comment it out safely (or just remove whole 70-mdadm.rules 
file). Then you can remove DEVICE line from mdadm.conf

> Thanks for getting me working
> 

np :)

  reply	other threads:[~2008-12-14 22:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-14 13:41 Raid 5 Problem nterry
2008-12-14 15:34 ` Michal Soltys
2008-12-14 20:41   ` nterry
2008-12-14 20:53     ` Justin Piszcz
2008-12-14 20:58       ` nterry
2008-12-14 21:03         ` Justin Piszcz
2008-12-14 21:08           ` Nigel J. Terry
2008-12-14 22:55           ` Michal Soltys
2008-12-14 21:14     ` Michal Soltys
2008-12-14 21:34       ` nterry
2008-12-14 22:02         ` Michal Soltys [this message]
2008-12-15 21:50         ` Neil Brown
2008-12-15 23:07           ` nterry
2008-12-16 20:39             ` nterry

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=49458286.7060802@ziu.info \
    --to=soltys@ziu.info \
    --cc=linux-raid@vger.kernel.org \
    --cc=nigel@nigelterry.net \
    /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).