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-27-2011, 12:59 PM
Philip Hands
 
Default mdadm and UUIDs for its component drives

On Sun, 26 Jun 2011 14:42:03 +0100, 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:
>
> > I hear what you are saying, but I had a related problem which was similar.
>
> well... it's funny, because this is exactly what i need.
>
> > 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. *;-)
>
>
>
> 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
>
> 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.

What I said was: "internal" bitmaps

madam(8):

-b, --bitmap=

Specify a file to store a write-intent bitmap in. The
file should not exist unless --force is also given. The
same file should be provided when assembling the array.
If the word internal is given, then the bitmap is stored
with the metadata on the array, and so is replicated on
all devices. If the word none is given with --grow mode,
then any bitmap that is present is removed.

To help catch typing errors, the filename must contain at
least one slash ('/') if it is a real file (not 'internal'
or 'none').

Note: external bitmaps are only known to work on ext2 and
ext3. Storing bitmap files on other filesystems may
result in serious problems.

and I probably also gave my half-arsed understanding of what that means.

Feel free to consult actual documentation for a proper understanding of
reality.

> also, he recommended taking at least one of the external drives *out*

I think I said: WTF? You buy a machine that had 4 hot swap SATA bays,
and you're plugging crappy external USB drives into it instead? Are you
mental? (or at least, if I didn't say that out loud, that's what I was
thinking ;-)

I must say that I'm a little beffuddled about how you managed to make
the system sensitive to which device contains which MD component -- I
seem to remember you mentioning that you had devices listed in your
mdadm.conf -- just get rid of them.

The mdadm.conf on one of my servers looks like this:

=-=-=-=-
DEVICE partitions
CREATE owner=root group=disk mode=0660 auto=yes
HOMEHOST <system>
MAILADDR root
ARRAY /dev/md/2 metadata=1.2 UUID=65c09661:02fc3a16:402916d3:5d4987f4 name=sheikh:2
ARRAY /dev/md/3 metadata=1.2 UUID=e82f516b:64bf463c:adf65c9c:fd728d05 name=sheikh:3
ARRAY /dev/md/4 metadata=1.2 UUID=56adc7ca:c7097e9b:00ac12c0:d1d278f2 name=sheikh:4
ARRAY /dev/md/5 metadata=1.2 UUID=6c5362e4:74b56fad:8c74a317:e4dce6d0 name=sheikh:5
ARRAY /dev/md/6 metadata=1.2 UUID=99ed31bd:cc608687:76f7b5a3:7bca24bc name=sheikh:6
ARRAY /dev/md/7 metadata=1.2 UUID=87cdaf12:94c2a356:4ba1d3bd:c80ac3b3 name=sheikh:7
ARRAY /dev/md/8 metadata=1.2 UUID=08e708b8:0989607b:d99709d2:8b5e4d58 name=sheikh:8
ARRAY /dev/md/11 metadata=1.2 UUID=210e1b53:3937b017:c947361e:2d2884b1 name=sheikh:11
=-=-=-=-

No mention of devices, which is a good job because that machine seems
to randomise the device mapping on each boot, and is capable of moving
them about when running if you pop the drive out of the machine and back
in again.

As also mentioned somewhere in the docs, the output of the command:

mdadm --examine --scan

can be used to populate the relevant bits of mdadm.conf

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
 
Old 06-28-2011, 03:51 PM
Tom H
 
Default mdadm and UUIDs for its component drives

On Mon, Jun 27, 2011 at 3:19 AM, martin f krafft <madduck@debian.org> wrote:
> 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

Exactly (my fault for misusing "partition").


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

On Mon, Jun 27, 2011 at 8:59 AM, Philip Hands <phil@hands.com> wrote:
>
> I must say that I'm a little beffuddled about how you managed to make
> the system sensitive to which device contains which MD component -- I
> seem to remember you mentioning that you had devices listed in your
> mdadm.conf -- just get rid of them.

I think that you may have resolved the OP's problem. I couldn't
understand why the newly-plugged-in USB disk might be considered a
member of the array. Having, for example,
"devices=/dev/sda1,/dev/sdb1" on the "ARRAY" line would probably do
it! Now the question is whether this is the OP's setup.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTi=ZdGaqNHPGKHLeuUC0QWBa_ZRncA@mail.gmail.com ">http://lists.debian.org/BANLkTi=ZdGaqNHPGKHLeuUC0QWBa_ZRncA@mail.gmail.com
 
Old 07-04-2011, 12:06 AM
Luke Kenneth Casson Leighton
 
Default mdadm and UUIDs for its component drives

On Mon, Jun 27, 2011 at 1:59 PM, Philip Hands <phil@hands.com> wrote:

>> *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.
>
> What I said was: "internal" bitmaps

ahh. yes. i missed the word "internal" but heard the good bits,
then looked up the man page and went "ohh, ok, that must be it". i
get there in the end


>> also, he recommended taking at least one of the external drives *out*
>
> I think I said: WTF?

ha ha

> *You buy a machine that had 4 hot swap SATA bays,
> and you're plugging crappy external USB drives into it instead? *Are you
> mental? *(or at least, if I didn't say that out loud, that's what I was
> thinking ;-)

i seem to remember the incredulity which definitely had the words
"are you mental??" behind it

> I must say that I'm a little beffuddled about how you managed to make
> the system sensitive to which device contains which MD component -- I
> seem to remember you mentioning that you had devices listed in your
> mdadm.conf -- just get rid of them.

well, i may have implied that, on account of not being able to
express it - i get it now: the things i thought were "devices" are
actually the UUIDs associated with the RAID array...

> ARRAY /dev/md/2 metadata=1.2 UUID=65c09661:02fc3a16:402916d3:5d4987f4 name=sheikh:2

... just like this.

> No mention of devices, which is a good job because that machine seems
> to randomise the device mapping on each boot, and is capable of moving
> them about when running if you pop the drive out of the machine and back
> in again.

yehhs, i noticed that. even the bloody boot drive comes up as
/dev/sde occasionally. last reboot i was adding drive 4 to the array,
it was named /dev/sda. kinda freaky.

ok.

so.

let's have a go at some updating the docs...

DESCRIPTION
RAID devices are virtual devices created from two or more real block
devices. This allows multiple devices (typically disk drives or parti‐
tions thereof) to be combined into a single device to hold (for exam‐
ple) a single filesystem. Some RAID levels include redundancy and so
can survive some degree of device failure.

Linux Software RAID devices are implemented through the md (Multiple
Devices) device driver. UUIDs are used internally through Linux Software
RAID to identify any device that is part of a RAID. In this
way, names may
change but the innocent are protected.

ok, scratch that last sentence

Linux Software RAID devices are implemented through the md (Multiple
Devices) device driver. UUIDs are used internally in Linux Software RAID
to identify any device that is part of a RAID, thus ensuring
that even if the
name changes (such as may happen if devices are removed and placed
into another system, or if using removable hot-swappable media) Linux
RAID can still correctly identify the component devices.

can we start with that - what you think, martin? it's right at the
top: it spells things out, and it makes linux RAID look good i'll
try to find appropriate places to put the same info, but the page is
really quite long. perhaps on "--add" somewhere?

l.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: CAPweEDxP2GFOWv0XJ9X6+0bMFi85W8mndR4czGY9XhV7Cp1rN A@mail.gmail.com">http://lists.debian.org/CAPweEDxP2GFOWv0XJ9X6+0bMFi85W8mndR4czGY9XhV7Cp1rN A@mail.gmail.com
 

Thread Tools




All times are GMT. The time now is 05:11 AM.

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