Interesting problem with MD array creation

[Patrick Ale]

Hi,

I have an interesting challenge, maybe one of you can help me :-)

I am creating an MD RAID 1 array consisting out of two SATA disks
(currently /dev/sdb1 and /dev/sdc1).
Both partitions use the Sun disk label and the partitions used start
on cylinder 1.

Device Flag    Start       End    Blocks   Id  System
/dev/sdb1             1     60788 488271577+  fd  Linux raid autodetect

Device Flag    Start       End    Blocks   Id  System
/dev/sdc1             1     60788 488271577+  fd  Linux raid autodetect

When I run the mdadm command to construct the array (mdadm --create
/dev/md0 --level=1 --raid-devices=2 --run /dev/sdb1 /dev/sdc1) all
goes fine, the array syncs up and all.

However, when you do a blkid -c /dev/null you'll see that both
/dev/sdb1 and /dev/sdc1 both share the same UUID.

/dev/sdb1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"
/dev/sdc1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"

This is a big problem since after a reboot it might be that /dev/sdb
becomes /dev/sda and /dev/sdc becomes /dev/sda (this actually happens,
both on x86 and sparc).
With other words, without having unique UUIDs there is no way you can
construct a proper /etc/mdadm.conf file and start the array
automaticly on every boot.

Any ideas on a work around?

Thanks,

Patrick

[Jon Masters]

On Wed, 2010-03-17 at 10:52 +0100, Patrick Ale wrote:
> /dev/sdb1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"
> /dev/sdc1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"

Interesting. Suggests that you have no entropy available to generate a
random UUID or something weirder is going on. Doe anyone happen to know
what is causing this, or should we persue the randomness not working?

Jon.

[Jon Masters]

On Wed, 2010-03-17 at 06:01 -0400, Jon Masters wrote:
> On Wed, 2010-03-17 at 10:52 +0100, Patrick Ale wrote:
> > /dev/sdb1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"
> > /dev/sdc1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"
>
> Interesting. Suggests that you have no entropy available to generate a
> random UUID or something weirder is going on. Doe anyone happen to know
> what is causing this, or should we persue the randomness not working?

Wait. I'm clearly smoking something, I thought you were looking at
something else. They're supposed to have the same UUID for the same md
RAID1 device. For the config, try just listing one of the members:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=<the UUID>

Jon.

[Patrick Ale]

On Wed, Mar 17, 2010 at 12:11 PM, Jon Masters  wrote:
> Wait. I'm clearly smoking something, I thought you were looking at
> something else. They're supposed to have the same UUID for the same md
> RAID1 device. For the config, try just listing one of the members:
>
> ARRAY /dev/md0 level=raid1 num-devices=2 UUID=<the UUID>

Works like a charm! Thank you,

Patrick

[Fabio M. Di Nitto]

On 3/17/2010 10:52 AM, Patrick Ale wrote:
> Hi,
>
> I have an interesting challenge, maybe one of you can help me :-)
>
> I am creating an MD RAID 1 array consisting out of two SATA disks
> (currently /dev/sdb1 and /dev/sdc1).
> Both partitions use the Sun disk label and the partitions used start
> on cylinder 1.
>
> Device Flag    Start       End    Blocks   Id  System
> /dev/sdb1             1     60788 488271577+  fd  Linux raid autodetect
>
> Device Flag    Start       End    Blocks   Id  System
> /dev/sdc1             1     60788 488271577+  fd  Linux raid autodetect
>
> When I run the mdadm command to construct the array (mdadm --create
> /dev/md0 --level=1 --raid-devices=2 --run /dev/sdb1 /dev/sdc1) all
> goes fine, the array syncs up and all.
>
> However, when you do a blkid -c /dev/null you'll see that both
> /dev/sdb1 and /dev/sdc1 both share the same UUID.
>
> /dev/sdb1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"
> /dev/sdc1: UUID="978635d6-52ab-c92b-76ea-5a12e49bd4b5" TYPE="linux_raid_member"

I had an interesting problem at some point in time with this setup where
silo and raid were not playing nicely together.

As workaround I used to add an empty partition at the beginning of the
disk (the smallest size as possible - basically just a padding
partition) on both RAID-1 disks and start using the disk for real from sdX2.

I have no clue if that problem has been addressed or not, but my
suggestion would be to check if you experience any kind of FS corruption
for files stored at the beginning of the raid disk before and after
asking silo to install/update the MBR.

Cheers
Fabio

[Jon Masters]

On Tue, 2010-03-23 at 06:06 +0100, Fabio M. Di Nitto wrote:
> I had an interesting problem at some point in time with this setup where
> silo and raid were not playing nicely together.

It'll depend upon which of the 3 different superblock types you have in
use (whether it is using the boot block for its data) - please see my
kernelpodcast.org for a summary of the issues.
> As workaround I used to add an empty partition at the beginning of the
> disk (the smallest size as possible - basically just a padding
> partition) on both RAID-1 disks and start using the disk for real from sdX2.

Or you can just begin a partition not at 0. I do a similar thing on my
Fedora 12 alpha Utra 5 in order to avoid any potential hiccups.

Jon.

[Fabio M. Di Nitto]

On 3/23/2010 8:01 AM, Jon Masters wrote:
> On Tue, 2010-03-23 at 06:06 +0100, Fabio M. Di Nitto wrote:
> > I had an interesting problem at some point in time with this setup where
> > silo and raid were not playing nicely together.
>
> It'll depend upon which of the 3 different superblock types you have in
> use (whether it is using the boot block for its data) - please see my
> kernelpodcast.org for a summary of the issues.

Right, at the time I was using the type that stores the RAID metadata at
the end of the disk (the old ones.. can´t remember the version number
right away), and that´s also why I specifically mentioned FS corruption
and not RAID corruption.
> > As workaround I used to add an empty partition at the beginning of the
> > disk (the smallest size as possible - basically just a padding
> > partition) on both RAID-1 disks and start using the disk for real from sdX2.
>
> Or you can just begin a partition not at 0. I do a similar thing on my
> Fedora 12 alpha Utra 5 in order to avoid any potential hiccups.

Indeed that´s also another solution.

Fabio

[Jon Masters]

On Tue, 2010-03-23 at 11:24 +0100, Fabio M. Di Nitto wrote:
> On 3/23/2010 8:01 AM, Jon Masters wrote:
> > On Tue, 2010-03-23 at 06:06 +0100, Fabio M. Di Nitto wrote:
> > > I had an interesting problem at some point in time with this setup where
> > > silo and raid were not playing nicely together.
> >
> > It'll depend upon which of the 3 different superblock types you have in
> > use (whether it is using the boot block for its data) - please see my
> > kernelpodcast.org for a summary of the issues.
>
> Right, at the time I was using the type that stores the RAID metadata at
> the end of the disk (the old ones.. can´t remember the version number
> right away), and that´s also why I specifically mentioned FS corruption
> and not RAID corruption.

Well, there's 0.90, 1.0, and 1.1. Peter favors 1.1 as a default IIRC,
since it is identical to 1.0 but at the end of the disk.
> > > As workaround I used to add an empty partition at the beginning of the
> > > disk (the smallest size as possible - basically just a padding
> > > partition) on both RAID-1 disks and start using the disk for real from sdX2.
> >
> > Or you can just begin a partition not at 0. I do a similar thing on my
> > Fedora 12 alpha Utra 5 in order to avoid any potential hiccups.
>
> Indeed that´s also another solution.

Yeah. Nice talking on IRC - it's been a long time dude since Spain!

Jon.