But this already happens with the SCSI device numbering, so no big change.
It would also happen if you have multi-path access to the RAID box (i.e.
two SCSI controllers), or with FC where there IS no "physical address",
or move the disks to a different type of SCSI controller (with a different
detection order than other controllers in the system), etc.
> Doesn't that mean the file specifying the RAID config is going to have
> to enumerate SCSI IDs (or something configuration invariant) as
> opposed to use the disk0..N numbering anyway?
No such thing as configuration invariant in some cases.
> Sure it can interrogate each disk0..N to see which has the ID that
> it actually wanted, but doesn't this rather subvert the purpose?
Not at all. To be robust, the (software) RAID system should ONLY access
disks that it knows belong to a given RAID set. To do otherwise is
useless. This is what LVM does, and it surprises me if MD RAID does
anything else (never really looked into it...).
In any case, a sane system would likely not expose all of the underlying
disks that make up a RAID set as a "disk", after that RAID set was built.
At configuration time, any /dev/disk{A,B,C} that went into the RAID
set would be removed, and the resulting RAID volume would become a new
/dev/diskX, just like any other disk in the system. If you really needed
more information about the RAID configuration, use the RAID tools to
query the attributes of /dev/diskX. That would solve a _lot_ of problems
with disks that make up meta-volumes being accessed via /dev/hdX instead
of /dev/mdY.
> IE, given one could create /dev/disk/?.+, isn't the important
> argument that they share common major device numbers etc., not whether
> they linearly reorder precisely to 0..N as opposed to have some form
> of identifier guaranteed to be static across reboot & config change.
I don't think the objective is necessarily to have a _packed_ device
numbering, nor one that changes randomly after each reboot, but just a
generic device naming independent of physical location, access method, etc.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/