changing major/minor numbers

changing major/minor numbers

[Kirill Malkin]

Hi,

I have a basic question about Linux RAID implementation: how to recover or
restart a RAID set when the individual disks are moved to a different SCSI
ID, i.e. when their minor (or major or both) number(s) change?

I've experimented with a RAID-1 configuration and found that whenever I move
one of the disks to a different SCSI ID, the set must be recovered manually
(i.e. raidhotadd) and the kernel initiates a full copy, even if raidtab is
manually updated (I guess the system simply looks at the superblocks as the
first choice). Is it possible to restart the set automatically or at least
avoid the full copy?

Another question: is there a utility that could identify RAID sets before
they are started, such as display the superblock contents and verify whether
any devices are missing or have been moved? There seems to be a considerable
amount of code, both in kernel and in raidtools, that prints out the content
of the superblocks, but only if there is a problem or debug mode is on.

The main reason behind these questions is the emergence of iSCSI devices
that could be connected in a random order thus breaking RAID functionality.
It would be nice to identify such devices up-front, make necessary
configuration changes and restart complete RAID sets without the full copy,
even if the disks come up as different major/minor numbers. Please let me
know if there's been any thinking in this direction.

Thank you in advance,
Kirill

Re: changing major/minor numbers

[Neil Brown]

On Thursday May 16, malkin@reldata.com wrote:
> Hi,
> 
> I have a basic question about Linux RAID implementation: how to recover or
> restart a RAID set when the individual disks are moved to a different SCSI
> ID, i.e. when their minor (or major or both) number(s) change?
> 
> I've experimented with a RAID-1 configuration and found that whenever I move
> one of the disks to a different SCSI ID, the set must be recovered manually
> (i.e. raidhotadd) and the kernel initiates a full copy, even if raidtab is
> manually updated (I guess the system simply looks at the superblocks as the
> first choice). Is it possible to restart the set automatically or at least
> avoid the full copy?
> 
> Another question: is there a utility that could identify RAID sets before
> they are started, such as display the superblock contents and verify whether
> any devices are missing or have been moved? There seems to be a considerable
> amount of code, both in kernel and in raidtools, that prints out the content
> of the superblocks, but only if there is a problem or debug mode is
> on.

Get mdadm.
   http://www.cse.unsw.edu.au/~neilb/source/mdadm/

(1.0.0 is recommended, 1.0.1 is experimental).

It should answer all your questions.

NeilBrown

> 
> The main reason behind these questions is the emergence of iSCSI devices
> that could be connected in a random order thus breaking RAID functionality.
> It would be nice to identify such devices up-front, make necessary
> configuration changes and restart complete RAID sets without the full copy,
> even if the disks come up as different major/minor numbers. Please let me
> know if there's been any thinking in this direction.
> 
> Thank you in advance,
> Kirill
> 
> 
> -
> 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