Debian and vendor proprietary RAID

Molle Bestefich molle.bestefich at gmail.com
Fri Apr 14 07:41:13 UTC 2006


András Imre wrote:
> I can mount the first partition. Now I'd like to mount the third, but
> the ntfs module complains about illegal structure. This is ok, since
> the partition is on the 2nd physical drive, and there is no partition
> table because of the JBOD setting.

I disagree that it's ok.

If dmraid enables RAID devices based on sd{a,b}, then the kernel
should IMHO be prevented from doing things such as creating wrong
devices for the partitions of the individual disks, such as you are
seeing here.

There's a couple of reasons I think that, but the principal one would
probably be to avoid confusing people into using these 'illegal'
partition devices.

> Q1: How can I mount the 3rd partition for the current system?

You'll need to have dmraid correctly assemble the array first.  See below...

> Q2: I'm about to reinstall the same structure but into a RAID0 array
> instead. I'd like to use Windows and Linux, and also have the advantage
> of striping. How can I make the installer to see the array? (dmraid
> does not come with the installer. All the installers I tried saw only
> two physical disks.)

The only graphical installer I know of that supports dmraid is
anaconda in Fedora Core 5.

If FC5 uses standard Grub, then it might nuke your RAID array
depending on the controller you use.  I know that Fedora Core 4 does
that on my HighPoint controller.

The Gentoo (text-based) installation system supports dmraid too.
That system will however for sure destroy HighPoint (others? dunno!..) arrays.

So even when you do find an installer that works, taking a backup of
your metadata before you start is not an entirely bad idea.  I learned
the hard way :-).

> # cat /proc/partitions
> major minor  #blocks  name
>
>    8     0   58605120 sda
>    8     1   29294496 sda1
>    8     2   29302560 sda2
>    8     3   58605120 sda3
>    8    16   58605120 sdb

Don't use sda{1,2,3}.
Pretend the kernel didn't make them :-).
(Technically, you can use some of the partitions if your setup is
SPAN, but I wouldn't.)

> dmraid version:         1.0.0.rc9 (2005.09.23)
> dmraid library version: 1.0.0.rc9 (2005.09.23)
> device-mapper version:  4.5.0

You should upgrade dmraid to the latest version before posting bug reports.

There's a dmraid<->devicemapper dependency, but it's not going to tell
you if your devicemapper is too old.  Instead you'll get obscure
warnings, but not on the console - only in /var/log/messages (or
wherever your syslog points).  So beware of that when upgrading.

> # dmraid -ay -vvv -d
> ERROR: opening "/dev/mapper/via_bdafghaihj"

This error is possibly because you've run dmraid -ay multiple times.
For testing purposes, it's probably a good idea to disable existing
dmraid devices with 'dmraid -an' before making debug output.

For best results, I'd use a live cd containing the newest version of dmraid.
If you get to the point where you need one, but cannot find one, let
me know and I'll make one for you.

> WARN: locking /var/lock/dmraid/.lock
> NOTICE: skipping removable device /dev/hda
> NOTICE: /dev/sda: hpt37x discovering
> NOTICE: /dev/sda: hpt45x discovering
> NOTICE: /dev/sda: isw    discovering
> NOTICE: /dev/sda: lsi    discovering
> NOTICE: /dev/sda: nvidia discovering
> NOTICE: /dev/sda: pdc    discovering
> NOTICE: /dev/sda: sil    discovering
> NOTICE: /dev/sda: via    discovering
> NOTICE: /dev/sda: via metadata discovered
> NOTICE: /dev/sdb: hpt37x discovering
> NOTICE: /dev/sdb: hpt45x discovering
> NOTICE: /dev/sdb: isw    discovering
> NOTICE: /dev/sdb: lsi    discovering
> NOTICE: /dev/sdb: nvidia discovering
> NOTICE: /dev/sdb: pdc    discovering
> NOTICE: /dev/sdb: sil    discovering
> NOTICE: /dev/sdb: via    discovering
> NOTICE: /dev/sdb: via metadata discovered
> DEBUG: _find_set: searching via_bdafghaihj
> DEBUG: _find_set: not found via_bdafghaihj
> DEBUG: _find_set: searching via_bdafghaihj
> DEBUG: _find_set: not found via_bdafghaihj
> NOTICE: added /dev/sda to RAID set "via_bdafghaihj"
> DEBUG: _find_set: searching via_bdafghaihj
> DEBUG: _find_set: found via_bdafghaihj
> DEBUG: _find_set: searching via_bdafghaihj
> DEBUG: _find_set: found via_bdafghaihj
> NOTICE: added /dev/sdb to RAID set "via_bdafghaihj"
> DEBUG: checking via device "/dev/sda"
> DEBUG: checking via device "/dev/sdb"
> DEBUG: set status of set "via_bdafghaihj" to 16
> RAID set "via_bdafghaihj" already active
> INFO: Activating linear RAID set "via_bdafghaihj"
> NOTICE: discovering partitions on "via_bdafghaihj"
> NOTICE: /dev/mapper/via_bdafghaihj: dos    discovering

Looks good to me!
You should have /dev/mapper/via_bdafghaihj{1,2,3} partition devices
available for use now!

What does "fdisk -l /dev/mapper/via_bdafghaihj" say?

> WARN: unlocking /var/lock/dmraid/.lock
> DEBUG: freeing devices of RAID set "via_bdafghaihj"
> DEBUG: freeing device "via_bdafghaihj", path "/dev/sda"
> DEBUG: freeing device "via_bdafghaihj", path "/dev/sdb"

Not sure what the above means.

> /dev/sda: via, "via_bdafghaihj", linear, ok, 117210239 sectors, data@ 0
> /dev/sdb: via, "via_bdafghaihj", linear, ok, 117210239 sectors, data@ 0

Looks reasonable, you can use 'dmsetup' to list the actual table
entries that dmraid creates.

HTH




More information about the Ataraid-list mailing list