From: Gilbert Kowarzyk <kowarzyk@grm.polymtl.ca>
To: Michal Soltys <soltys@ziu.info>
Cc: linux-raid@vger.kernel.org
Subject: Re: Renaming MD devices (metadata=1.1)
Date: Wed, 11 Jan 2012 01:07:38 -0500 [thread overview]
Message-ID: <4F0D272A.2060000@grm.polymtl.ca> (raw)
In-Reply-To: <4F0C1A03.8020509@ziu.info>
Hello,
Thanks for the quick answer. My replies are below.
>> # mdadm --examine --scan /dev/sdc1
>> =================================>
>> ARRAY /dev/md/9 metadata=1.1 UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>> name=xyz.homelinux.com:9
>> <=================================
>>
>>
>> # mdadm --examine --scan /dev/sdd1
>> =================================>
>> ARRAY /dev/md/9 metadata=1.1 UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>> name=xyz.homelinux.com:9
>> <=================================
>>
>>
>> # mdadm --detail --scan
>> =================================>
>> ARRAY /dev/md/xyz.homelinux.com:9 metadata=1.1
>> name=xyz.homelinux.com:9 UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>> <=================================
>>
>> # blkid
>> =================================>
>> /dev/md127: UUID="c301cf13-cfaf-4f56-887e-c648caf5a931" TYPE="ext4"
>> <=================================
>>
>> in /etc/fstab I have:
>> =================================>
>> UUID=c301cf13-cfaf-4f56-887e-c648caf5a931 /DATA ext4 defaults 1 2
>> <=================================
>>
>> and in /etc/mdadm.conf I have:
>> =================================>
>> ARRAY /dev/md/xyz.homelinux.com:9 metadata=1.1
>> name=xyz.homelinux.com:9 UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>> <=================================
>>
>>
>> To me, the line that looks suspicious is the one we get from "mdadm
>> - --detail --scan". All the devices that "look right" say "ARRAY
>> /dev/md/X" where X is a number.
>>
>> I fixed this temporarily by stopping the array and re-assembling it with:
>>
>> mdadm --assemble /dev/md9 --name=9 --update=name /dev/sdc1 /dev/sdd1
>>
>
> You updated name stored in the metadata, and assembled the array
> explicitly requesting particular standard name. But the names directly
> under /dev are managed/assigned by udev.
>
> As the /dev/md9 was explicitly given in this form, the MD_DEVNAME was
> not present in 'mdadm --detail --export' output, thus /dev/md/9 was not
> created by mdadm's udev rules - but it would have been if you had done
> mdadm --assemble /dev/md/9 ...
Ok, I think I follow this, but I am not sure.
What you are saying is that I am getting /dev/md127 because it's not
being created by udev right?
>> Then the mdadm --detail --scan line says:
>> ARRAY /dev/md/9 metadata=1.1 name=xyz.homelinux.com:9
>> UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>>
>> ... which makes more sense to me (it looks like the other ones.
>>
>> Yet, when I reboot the computer this "temporarily fixed" array returns
>> to /dev/md127.
>
> But you should have proper, permanent name (as a symlink) under /dev/md/
I just checked, and indeed I do. The symlinks I have under /dev/md/ are
exactly the ones relating to the md devices I am having problems with
renaming.
There are no symlinks for the other md devices.
> Autoassembly (be it -I used with modern mdadm's udev rules) or -A will
> try to honor the device name if the name is in standard format, so for
> mdadm.conf with ARRAY /dev/md/9 ... - you will (usually) get /dev/md9 -
> but this it's not really worth chasing after or relying on (and what if
> the name is already taken ?).
>
> Just write:
>
> ARRAY /dev/md/somename UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
> ARRAY somename UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>
> in which case 'somename' will be created under /dev/md/ regardless of
> the name stored in the metadata, or just
>
> ARRAY UUID=0fa7f737:7806ca61:fb89edd6:14aa351a
>
> so the metadata (without hostname prefix) will be used.
so expliciting the metadata=x is not needed? What's its use?
> So to sum it up - if '9' is what you're after - then the ARRAY line with
> just UUID is all you should be needing - and you should always get
> /dev/md/9 (pointing to something else assigned dynamically).
>
> If udevd is not running (hardly interesting case anymore), then mdadm
> will fall back to the pre-udev behavior and setup the nodes itself,
> though the rules are slightly different then.
I just left ARRAY UUID=0fa7f737:7806ca61:fb89edd6:14aa351a in
/etc/mdadm.conf, rebooted, and it's still appearing as /dev/md127.
So I am not sure why... What may I be missing?
Thanks,
Gilbert
next prev parent reply other threads:[~2012-01-11 6:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 6:12 Renaming MD devices (metadata=1.1) Gilbert Kowarzyk
2012-01-10 10:59 ` Michal Soltys
2012-01-11 6:07 ` Gilbert Kowarzyk [this message]
2012-01-11 6:20 ` NeilBrown
2012-01-11 6:39 ` Gilbert Kowarzyk
2012-01-11 7:03 ` NeilBrown
2012-01-11 16:01 ` Gilbert Kowarzyk
2012-01-11 23:04 ` NeilBrown
2012-01-12 0:08 ` Gilbert Kowarzyk
2012-01-10 12:49 ` Phil Turmel
2012-01-11 6:23 ` Renaming MD devices (metadata=1.1) [SOLVED] Gilbert Kowarzyk
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=4F0D272A.2060000@grm.polymtl.ca \
--to=kowarzyk@grm.polymtl.ca \
--cc=linux-raid@vger.kernel.org \
--cc=soltys@ziu.info \
/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