From: Marcin Krol <admin@domeny.pl>
To: linux-raid@vger.kernel.org
Subject: Re: Deleting mdadm RAID arrays
Date: Fri, 8 Feb 2008 10:35:25 +0100 [thread overview]
Message-ID: <200802081035.25722.admin@domeny.pl> (raw)
In-Reply-To: <47AB79B1.6000503@tmr.com>
Thursday 07 February 2008 22:35:45 Bill Davidsen napisał(a):
> > As you may remember, I have configured udev to associate /dev/d_* devices with
> > serial numbers (to keep them from changing depending on boot module loading
> > sequence).
> Why do you care?
Because /dev/sd* devices get swapped randomly depending on boot module insertion
sequence, as I explained earlier.
> If you are using UUID for all the arrays and mounts
> does this buy you anything?
This is exactly what is not clear for me: what is it that identifies drive/partition as part of
the array? /dev/sd name? UUID as part of superblock? /dev/d_n?
If it's UUID I should be safe regardless of /dev/sd* designation? Yes or no?
> And more to the point, the first time a
> drive fails and you replace it, will it cause you a problem? Require
> maintaining the serial to name data manually?
That's not the problem. I just want my array to be intact.
> I miss the benefit of forcing this instead of just building the
> information at boot time and dropping it in a file.
I would prefer that, too - if it worked. I was getting both arrays messed
up randomly on boot. "messed up" in the sense of arrays being composed
of different /dev/sd devices.
> > And I made *damn* sure I zeroed all the superblocks before reassembling
> > the arrays. Yet it still shows the old partitions on those arrays!
> >
> As I noted before, you said you had these on whole devices before, did
> you zero the superblocks on the whole devices or the partitions? From
> what I read, it was the partitions.
I tried it both ways actually (rebuilt arrays a few times, just udev didn't want
to associate WD-serialnumber-part1 as /dev/d_1p1 as it was told, it still claimed
it was /dev/d_1).
Regards,
Marcin Krol
-
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:[~2008-02-08 9:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-05 10:42 Deleting mdadm RAID arrays Marcin Krol
2008-02-05 11:43 ` Moshe Yudkowsky
2008-02-06 9:35 ` Marcin Krol
2008-02-05 12:27 ` Janek Kozicki
2008-02-05 13:52 ` Michael Tokarev
2008-02-05 14:33 ` Moshe Yudkowsky
2008-02-05 15:16 ` Michael Tokarev
2008-02-05 14:47 ` Auto generation of mdadm.conf (was: Deleting mdadm RAID arrays) Janek Kozicki
2008-02-05 15:34 ` Auto generation of mdadm.conf Michael Tokarev
2008-02-05 18:39 ` Janek Kozicki
2008-02-05 20:12 ` Deleting mdadm RAID arrays Neil Brown
2008-02-06 9:55 ` Marcin Krol
2008-02-06 10:11 ` Peter Rabbitson
2008-02-06 10:32 ` Marcin Krol
2008-02-06 10:43 ` Neil Brown
2008-02-06 12:03 ` Marcin Krol
2008-02-07 2:36 ` Neil Brown
2008-02-07 9:56 ` Marcin Krol
2008-02-07 21:35 ` Bill Davidsen
2008-02-08 9:35 ` Marcin Krol [this message]
2008-02-08 12:44 ` Bill Davidsen
2008-02-08 12:52 ` Marcin Krol
2008-02-06 19:03 ` Bill Davidsen
2008-02-06 11:22 ` David Greaves
2008-02-06 11:56 ` Marcin Krol
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=200802081035.25722.admin@domeny.pl \
--to=admin@domeny.pl \
--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).