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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.