From: Bill Davidsen <davidsen@tmr.com>
To: Michael Schmitt <mschmitt@unixkiste.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: confusion about partitionable md arrays
Date: Sat, 30 Dec 2006 17:08:53 -0500 [thread overview]
Message-ID: <4596E375.4070900@tmr.com> (raw)
In-Reply-To: <1167381105.12758.57.camel@localhost.localdomain>
Michael Schmitt wrote:
> Hi Bill,
>
> this `thing´ works in another computer and as I moved it to another one,
> I could not get it working. So the problem is... somewhere in between :)
> As I had other non md-related problems in this computer (power supply
> insufficient, system could not boot from hda anymore when sata disks
> were connected to the pci-controller so I needed to unplug the sata
> cables until grub has loaded, BIOS upgrade did not help), I moved the
> array back in the original one, and it worked without a change.
>
> But I noticed there a different behavior "Generating udev events for MD
> arrays" showed up during boot, listing the partitions md0_d0p1 to
> md0_d0p4 and of course /dev/md0_d0pN showed up. Then I cogitated about
> all that a bit and came to some possible conclusions. Maybe the nameing
> scheme for the arrays need to reflect somehow if it is a partibionable
> array or not, if there are partitions and if udev needs to add the
> appropriate devices... or not. Then I remembered some of the strange
> things which happend when I did set up the array in the first place. I
> tried to name the array "md0" but /dev/md_0" was generated too. /dev/md0
> was somehow "dead" and my array was accessible as /dev/md0_d0. A bit
> later as I tried to build an array with IDE discs in the "troublesome"
> computer, I noticed similar effects. I tried to name the array
> simple /dev/array1 but /dev/md127_d0 (iirc) was generated
> too. /dev/array1 was dead and the raid was accessible at /dev/md127_d0.
> So, whats all that? Even if I had read somehwere the name of the device
> can be anything, it may be that that's not really true.
>
> So the question remains the same, the confusion is persistent as the
> superblocks in my arrays :) Any input is appreciated.
>
> I already did read some mails in this list but did not get the point and
> no real explanation to my question. I will read on, maybe I get
> enlightenment.
>
I just reread the man page, and there is a paragraph on partitionable
arrays following the "-a" option. Having warned you that I'm not
experienced in this, I wonder if there is some interaction between
device names created by "-amdp" and rules for udev, and how much of this
partition info is carried in the superblock. There's a lot of discussion
of names in that paragraph.
I also wonder if using the "-amdp" vs. just "-ap" will work differently.
Hopefully Neil will have words of wisdom if we continue to thrash
without a good understanding.
> greetings
> Michael
>
> Am Donnerstag, den 28.12.2006, 22:20 -0500 schrieb Bill Davidsen:
>
>> Michael Schmitt wrote:
>>
>>> Hi list,
>>>
>>> since recent releases obviously it is possible to build an array and
>>> partition that instead of building an array out of partitions. This was
>>> somehow confusing but it worked in the first place. Now I moved the
>>> array from one machine to another and... now it gets somehow strange. I
>>> have nothing in /dev/md/ but /dev/md0. If I do fdisk -l it lists the
>>> partitions /dev/md0p1 to /dev/md0p4, set to type 83 but there are no
>>> devices under /dev/ or in /proc/partitions for them. I've read the
>>> archives and googled around but there was no real solution just
>>> different meanings on how it should be and how such things come. I'd
>>> really appreciate a definite answer how that should work with
>>> partitionable arrays and in best cases, what my problem may be here :)
>>>
>>> At the end of this mail are the mdstat and mdadm outputs for reference
>>>
>>>
>>>
>> I'm not sure you have a problem, if this whole thing works correctly.
>> However, there has been discussion about the implications of using whole
>> drives instead of partitions to build your array. Having avoided that
>> particular path I'm not going to rehash something I marginally
>> understand, but some reading of post in the last few months may shed
>> understanding.
>>
>>
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
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
prev parent reply other threads:[~2006-12-30 22:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-26 19:27 confusion about partitionable md arrays Michael Schmitt
2006-12-29 3:20 ` Bill Davidsen
2006-12-29 8:31 ` Michael Schmitt
2006-12-30 22:08 ` Bill Davidsen [this message]
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=4596E375.4070900@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-raid@vger.kernel.org \
--cc=mschmitt@unixkiste.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.