lkml.org 
[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: LANANA: To Pending Device Number Registrants
Date
Alex Bligh writes:
> Q: Let us assume you have dynamic numbering disk0..N as you suggest,
> and you have some s/w RAID of SCSI disks. A disk fails, and is (hot)
> removed. Life continues. You reboot the machine. Disks are now numbered
> disk0..(N-1). If the RAID config specifies using disk0..N thusly, it
> is going to be very confused, as stripes will appear in the wrong place.

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/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.180 / U:2.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site