FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 06-26-2011, 03:53 PM
Luke Kenneth Casson Leighton
 
Default mdadm and UUIDs for its component drives

On Sun, Jun 26, 2011 at 4:26 PM, martin f krafft <madduck@debian.org> wrote:
> also sprach Luke Kenneth Casson Leighton <luke.leighton@gmail.com> [2011.06.26.1634 +0200]:
>> > Search manpage for "partitions".
>>
>> ¬*that's odd. ¬*i read around each part (man mdadm^M /partitions^M),
>> ¬*paragraph back and forwards: no mention of the UUIDs of drive
>> ¬*components of an array was clearly evident.
>
> I was not trying to suggest that there was a mention of the UUIDs.
> mdadm's manpage only mentions /proc/partitions; it scans that "file"
> and then looks for UUIDs on each of the listed partitions, building
> a list indexed by UUID [0].

ahh, ok. that's very cool.

> And now it has the list of devices (partitions) that constitute
> individual arrays identified by UUID…
>
> 0. not sure this is the actual implementation…



>> > Please suggest patches if you find the information insufficient.
>>
>> ¬*ok. ¬*feeling slightly overwhelmed by the task, my lack of
>> ¬*knowledge on the detailed workings of mdadm somewhat getting in
>> ¬*the way, but i'll do my best.
>
> I'll try my best to provide feedback.

thx.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinnAoUdU409W1+EVY+Adrv7-SZYAw@mail.gmail.com">http://lists.debian.org/BANLkTinnAoUdU409W1+EVY+Adrv7-SZYAw@mail.gmail.com
 
Old 06-26-2011, 06:05 PM
Andrew McGlashan
 
Default mdadm and UUIDs for its component drives

Hi,

Luke Kenneth Casson Leighton wrote:

well. that was nice. the scenario you describe is precisely what i
sort-of had planned, but didn't have the expertise to do so was going
to recommend just two drives and then rsync to the other two.

_however_, given that you've solved exactly what is needed / best /
recommended for when you have 4 external drives (which i do) that's
bloody fantastic


Great, hope it helps!


ok, i bring in phil now, who i was talking to yesterday about this.
what he said was (and i may get this wrong: it only went in partly) -
something along the lines of "remember to build the drives with
individual mdadm bitmaps enabled". this will save a great deal of
arseing about when re-adding drives which didn't get properly added:
only 1/2 a 1Tb drive will need syncing, not an entire drive the
bitmap system he says has hierarchical granularity apparently.


I just added a bitmap, more info. here [1] & [2] -- worth a read. You
can add and remove them, sometimes you must remove them ... for
instance, if growing the array.


Quote from [2] reference:

"In some configurations you may not be able to grow the array until you
have removed the internal bitmap. You can add the bitmap back again
after the array has been grown."


It also seems best to use internal for the bitmap from my reading, so
this is what I did for that.tip:


# mdadm --grow --bitmap=internal /dev/md0


also, he recommended taking at least one of the external drives *out*
of its external box and making it *internal*. the reason for that is
that a) if the drives ever get powered down accidentally (e.g. by
cleaning ladies) you're f****d b) if you move a drive or two
internally, it's possible to prioritise those drives as "reading"
ones, and to make the external ones "write" priority. so, the data
gets read from the internal one, and changes get propagated to all
drives.


Yes, that sounds like a good idea(tm) ... worth considering, but right
now I prefer all the RAID drive members external on this particular
machine. The drives and machine are all on a suitable UPS and there is
no cleaning lady to worry about -- my wife won't touch the drives either.


Down the track, I'm sure to move to USB 3.0 and maybe even further down
the track to external PCI Express ... [3], which looks interesting. And
more so in the future, IBM Racetrack memory [4] which looks to replace
the "drive" as we know it today.



[1] https://raid.wiki.kernel.org/index.php/Write-intent_bitmap

[2] http://en.wikipedia.org/wiki/Mdadm

[3]
http://www.zdnet.com/blog/computers/look-out-thunderbolt-external-pci-express-spec-being-developed/6220?tag=nl.e539

[4] http://www.youtube.com/watch?v=q5jRHZWQ0sc

--
Kind Regards
AndrewM


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E0774DE.8070806@affinityvision.com.au">http://lists.debian.org/4E0774DE.8070806@affinityvision.com.au
 
Old 06-26-2011, 08:58 PM
Tom H
 
Default mdadm and UUIDs for its component drives

On Sun, Jun 26, 2011 at 6:41 AM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
>
> is there an option to mdadm to make it display UUIDs instead of or
> as well as the disk name?

"mdadm --examine /dev/sdXY" gives you the device and the array UUIDs.

"mdadm --examine --scan" gives you the array UUID(s).

"mdadm --detail /dev/mdZ" gives you the array UUID.

"mdadm --detail --scan" gives you the array UUID(s).


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=PT6M41iwNqUyVoc5Yuv1AgmKVsQ@mail.gmail.com ">http://lists.debian.org/BANLkTi=PT6M41iwNqUyVoc5Yuv1AgmKVsQ@mail.gmail.com
 
Old 06-26-2011, 09:11 PM
Tom H
 
Default mdadm and UUIDs for its component drives

On Sun, Jun 26, 2011 at 9:55 AM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
> On Sun, Jun 26, 2011 at 2:25 PM, Andrew McGlashan
> <andrew.mcglashan@affinityvision.com.au> wrote:
>
>> Anyway.... the long and short of it is, I can use mdadm without regard to
>> what devices are found, such as /dev/sda /dev/sdb /dev/sdc and the like as I
>> rely purely on the UUID functionality, which as you know, mdadm handles
>> perfectly well. *;-)
>
> *
>
> *...mmmm you see, this is the bit that has me concerned. */dev/mdN can
> be referred to by its unique UUID, but that's *not* what i'm referring
> to. *and, from what you're saying, you appear to be implying that yes,
> the external drives can pop up as /dev/sda through /dev/sdc and be
> "confused" - and thus it is pure luck (or actually design) that the
> drives *happen* to all be part of the same identical RAID-1 mirroring
> array.
>
> *so i realise martin that you've already answered, but it would be
> really good if you could explicitly confirm:
>
> *yes, mdadm names its RAID drives by UUID (as can clearly be seen in
> /dev/mdadm/mdadm.conf) but does it *also* refer to its *COMPONENT*
> drives (internally, and non-obviously, and undocumentedly) by UUID and
> then report to the outside world that it's using whatever name
> (/dev/sdX) which can, under these external-drives scenario, change.

I've never plugged a USB drive into a mdadm'd box so I'm trying to get
my head around this - and check whether I'm understanding you
correctly.

You have "/" set up as a RAID 1 array md0 with sda1 and sdb1 as its components.

You plug in a USB drive and its first/only partition become sda1.

mdadm tries to assemble the USB drive's sda1 with sdb1 (whether it's
the old sda1 or the old sdb1) even though sda1 doesn't have md0's
(array) UUID in its metadata, let alone any mdadm metadata!


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTikSkfmyc1vLkD+cd=jjKYvXQ8RMrA@mail.gmail.com ">http://lists.debian.org/BANLkTikSkfmyc1vLkD+cd=jjKYvXQ8RMrA@mail.gmail.com
 
Old 06-26-2011, 09:28 PM
Tom H
 
Default mdadm and UUIDs for its component drives

On Sun, Jun 26, 2011 at 11:29 AM, William Hopkins <we.hopkins@gmail.com> wrote:
>
> It seems to me that you'd be well served by simply using the UUID (by-uuid, not
> by-id) in all things, including mounting and managing. Then you would never
> need to figure out which disk sda was, you could just figure out which disk the
> UUID was (and you'd only have to learn it once).

There are UUIDs and UUIDs.

For an array md0 with sda1 and sdb1 as its components.

"blkid /dev/md0" returns the filesystem UUID.

"mdadm --detail /dev/md0" returns the mdadm UUID of the array.

"blkid /dev/sda1" returns the mdadm UUID of the array.

"mdadm --examine /dev/sda1" returns mdadm UUIDs of the array and the
partition. (I've never seen the mdadm UUID of a partition be used for
anything. Can an array be assembled by referring to an mdadm UUID of a
partition to add a partition? Would it make any sense?!)

The "/dev/disk/by-id/" symlinks are the most stable ones (for a
specific disk) should anyone want to use them because they're hardware
IDs. I don't have an mdadm'd box at hand to check but I think that
md0's entry in this directory includes the mdadm array UUID of md0
because md0 doesn't have a "real" hardware ID. So, for md0,
"/dev/disk/by-id" and "/dev/disk/by-uuid" are equivalent.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=_s+TLs+x84Q-n_4eWn2MwAfvA+g@mail.gmail.com">http://lists.debian.org/BANLkTi=_s+TLs+x84Q-n_4eWn2MwAfvA+g@mail.gmail.com
 
Old 06-27-2011, 04:52 AM
martin f krafft
 
Default mdadm and UUIDs for its component drives

also sprach Tom H <tomh0665@gmail.com> [2011.06.26.2328 +0200]:
> "mdadm --examine /dev/sda1" returns mdadm UUIDs of the array and
> the partition. (I've never seen the mdadm UUID of a partition be
> used for anything. Can an array be assembled by referring to an
> mdadm UUID of a partition to add a partition? Would it make any
> sense?!)

Partitions do not have UUIDs. What you are seeing are the MD UUIDs
stored in the superblock of the sda1 device.

--
.'`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems

"a woman is like your shadow;
follow her, she flies;
fly from her, she follows."
-- sťbastien-roch-nicolas chamfort
 
Old 06-27-2011, 05:51 AM
Andrew McGlashan
 
Default mdadm and UUIDs for its component drives

Tom H wrote:

You have "/" set up as a RAID 1 array md0 with sda1 and sdb1 as its components.


No / would be on an internal drive, right now that is not the concern
as it has nothing to do with the external drive array(s) in question for
this issue.


--
Kind Regards
AndrewM


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E081A5E.5060408@affinityvision.com.au">http://lists.debian.org/4E081A5E.5060408@affinityvision.com.au
 
Old 06-27-2011, 06:51 AM
Tom H
 
Default mdadm and UUIDs for its component drives

On Mon, Jun 27, 2011 at 12:52 AM, martin f krafft <madduck@debian.org> wrote:
> also sprach Tom H <tomh0665@gmail.com> [2011.06.26.2328 +0200]:
>>
>> "mdadm --examine /dev/sda1" returns mdadm UUIDs of the array and
>> the partition. (I've never seen the mdadm UUID of a partition be
>> used for anything. Can an array be assembled by referring to an
>> mdadm UUID of a partition to add a partition? Would it make any
>> sense?!)
>
> Partitions do not have UUIDs. What you are seeing are the MD UUIDs
> stored in the superblock of the sda1 device.

I called them "mdadm UUIDs" rather than "MD UUIDs" but they definitely
exist, are different from the "MD Array UUID", and, AFAIK, unused by
the user tools.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTim1b7Lr2=ONRTNJ9NPcGB3OrVeGXQ@mail.gmail.com ">http://lists.debian.org/BANLkTim1b7Lr2=ONRTNJ9NPcGB3OrVeGXQ@mail.gmail.com
 
Old 06-27-2011, 06:54 AM
Tom H
 
Default mdadm and UUIDs for its component drives

On Mon, Jun 27, 2011 at 1:51 AM, Andrew McGlashan
<andrew.mcglashan@affinityvision.com.au> wrote:
> Tom H wrote:
>>
>> You have "/" set up as a RAID 1 array md0 with sda1 and sdb1 as its
>> components.
>
> No / would be on an internal drive, *right now that is not the concern as it
> has nothing to do with the external drive array(s) in question for this
> issue.

Thanks for explaining...

Forget about "/". Your external array is mounted on "/path/to/array"
and its members are sdXA and sdYA. When you plug in another USB drive,
it becomes sdXA or sdYA and mdadm tries to assemble it into the array
even though it doesn't have any mdadm metadata whatsoever.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinObgAe22s=1g8LC0vvthoAwjqEKA@mail.gmail.com ">http://lists.debian.org/BANLkTinObgAe22s=1g8LC0vvthoAwjqEKA@mail.gmail.com
 
Old 06-27-2011, 07:19 AM
martin f krafft
 
Default mdadm and UUIDs for its component drives

also sprach Tom H <tomh0665@gmail.com> [2011.06.27.0851 +0200]:
> > Partitions do not have UUIDs. What you are seeing are the MD UUIDs
> > stored in the superblock of the sda1 device.
>
> I called them "mdadm UUIDs" rather than "MD UUIDs" but they definitely
> exist, are different from the "MD Array UUID", and, AFAIK, unused by
> the user tools.

I misunderstood you. Partitions do not have UUIDs, but you were
talking about individual array constituents ‚ÄĒ those do have UUIDs
that are separate from the array UUID.

# mdadm --examine /dev/sda2 | grep UUID
Array UUID : bfb705a9:69bfc685:92b80aa8:ff445936
Device UUID : ed7cb6d2:32f8dda4:bdd22f74:c4ef720b

--
.'`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems

"alas, i am dying beyond my means."
-- oscar wilde
 

Thread Tools




All times are GMT. The time now is 01:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org