From: Bill Davidsen <davidsen@tmr.com>
To: Marcin Krol <admin@domeny.pl>
Cc: linux-raid@vger.kernel.org
Subject: Re: Deleting mdadm RAID arrays
Date: Thu, 07 Feb 2008 16:35:45 -0500 [thread overview]
Message-ID: <47AB79B1.6000503@tmr.com> (raw)
In-Reply-To: <200802071056.33221.admin@domeny.pl>
Marcin Krol wrote:
> Thursday 07 February 2008 03:36:31 Neil Brown napisał(a):
>
>
>>> 8 0 390711384 sda
>>> 8 1 390708801 sda1
>>> 8 16 390711384 sdb
>>> 8 17 390708801 sdb1
>>> 8 32 390711384 sdc
>>> 8 33 390708801 sdc1
>>> 8 48 390710327 sdd
>>> 8 49 390708801 sdd1
>>> 8 64 390711384 sde
>>> 8 65 390708801 sde1
>>> 8 80 390711384 sdf
>>> 8 81 390708801 sdf1
>>> 3 64 78150744 hdb
>>> 3 65 1951866 hdb1
>>> 3 66 7815622 hdb2
>>> 3 67 4883760 hdb3
>>> 3 68 1 hdb4
>>> 3 69 979933 hdb5
>>> 3 70 979933 hdb6
>>> 3 71 61536951 hdb7
>>> 9 1 781417472 md1
>>> 9 0 781417472 md0
>>>
>> So all the expected partitions are known to the kernel - good.
>>
>
> It 's not good really!!
>
> I can't trust /dev/sd* devices - they get swapped randomly depending
> on sequence of module loading!! I have two drivers, ahci for onboard
> SATA controllers and sata_sil for additional controller.
>
> Sometimes the system boots ahci first and sata_sil later, sometimes
> in reverse sequence.
>
> Then, sda becomes sdc, sdb becomes sdd, etc.
>
> It is exactly the problem that I cannot rely on kernel's information which
> physical drive is which logical drive!
>
>
>> Then
>> mdadm /dev/md0 -f /dev/d_1
>>
>> will fail d_1, abort the recovery, and release d_1.
>>
>> Then
>> mdadm --zero-superblock /dev/d_1
>>
>> should work.
>>
>
> Thanks, though I managed to fail the drives, remove them, zero superblocks
> and reassemble the arrays anyway.
>
> The problem I have now is that mdadm seems to be of 'two minds' when it comes
> to where it gets the info on which disk is what part of the array.
>
> 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? If you are using UUID for all the arrays and mounts
does this buy you anything? 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?
I miss the benefit of forcing this instead of just building the
information at boot time and dropping it in a file.
> Now, when I swap two (random) drives in order to test if it keeps device names
> associated with serial numbers I get the following effect:
>
> 1. mdadm -Q --detail /dev/md* gives correct results before *and* after the swapping:
>
> % mdadm -Q --detail /dev/md0
> /dev/md0:
> [...]
> Number Major Minor RaidDevice State
> 0 8 1 0 active sync /dev/d_1
> 1 8 17 1 active sync /dev/d_2
> 2 8 81 2 active sync /dev/d_3
>
> % mdadm -Q --detail /dev/md1
> /dev/md1:
> [...]
> Number Major Minor RaidDevice State
> 0 8 49 0 active sync /dev/d_4
> 1 8 65 1 active sync /dev/d_5
> 2 8 33 2 active sync /dev/d_6
>
>
> 2. However, cat /proc/mdstat gives shows different layout of the arrays!
>
> BEFORE the swap:
>
> % cat mdstat-16_51
> Personalities : [raid6] [raid5] [raid4]
> md1 : active raid5 sdb1[2] sdf1[0] sda1[1]
> 781417472 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>
> md0 : active raid5 sde1[2] sdc1[0] sdd1[1]
> 781417472 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>
> unused devices: <none>
>
>
> AFTER the swap:
>
> % cat /proc/mdstat
> Personalities : [raid6] [raid5] [raid4]
> md1 : active(auto-read-only) raid5 sdd1[0] sdc1[2] sde1[1]
> 781417472 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>
> md0 : active(auto-read-only) raid5 sda1[0] sdf1[2] sdb1[1]
> 781417472 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>
> unused devices: <none>
>
> I have no idea now if the array is functioning (it keeps the drives
> according to /dev/d_* devices and superblock info is unimportant)
> or if my arrays fell apart because of that swapping.
>
> 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.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
-
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-07 21: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 [this message]
2008-02-08 9:35 ` Marcin Krol
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=47AB79B1.6000503@tmr.com \
--to=davidsen@tmr.com \
--cc=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.