> On Fri, 2003-04-11 at 20:13, Paul McKenney wrote:
> > Some compatibility needs more code than other compatibility.
> > The desired compatibility includes the following, much of which
> > has been noted earlier in this thread, and some of which may
> > need to wait for multipath I/O and other of which might be best
> > provided by a volume manager:
>
> We're talking about two types of compatibility. The first (which
> everyone agrees on) is that /dev names don't change between 2.4 and
> 2.5. The second is direct numerical compatibility so that a /dev still
> using the old 8:8 scheme works.
>
> What you're asking for is more a wish list of enhancements:
True, and the more disks one has, the more one would be wishing
for them.
> > o It must be possible to switch between 2.4 and 2.5/6
> > kernels without a given disk's name changing.
>
> By and large, this is true. There will be problems where probe order
> has altered because of changes to bus enumeration schemes or for other
> reasons.
Exactly.
> > o New 2.5/6 installations should se a clean disk naming
> > scheme without historical cruft.
>
> They'll all see /dev/sd<A>[n] as in 2.4
>
> > o Removing or adding one disk should not affect the
> > names of other disks. Ideally, moving a given disk
> > from one place to another should not change its
> > name. "The good news is that we repaired your
> > disk. The bad news is that, due to the resulting
> > name changes, your application thoroughly
> > corrupted all of its data."
>
> True until a reboot, as in 2.4
Again, exactly. The current state requires the sysadm to
disable the application automatically running on reboot so
that the application's pathnames could be changed -- after
the sysadm works out what the names have changed to. Ouch.
This does not necessarily need to be done in the kernel,
one could use a volume manager as noted above, or udev
with appropriate plugins, as you noted below.
> > o Adding or removing a FC or SCSI adapter should not
> > affect the names of disks hanging off of other
> > FC or SCSI controllers. Ideally, the name of
> > a disk should not change when its FC or SCSI
> > controller is moved from one slot to another.
>
> That's not a 2.4 guarantee, it won't be a 2.5 one.
Again, one really does not want to have to figure out
which disk changed to what name, then hand-edit all
mount commands, application config files, etc. to change
all the disk and partition names.
And again, something like udev or a volume manager might
be appropriate if this functionality is not to be provided
by the base kernel itself.
> > o Failures of or repairs to the FC fabric should
> > not change the names of any of the disks (though
> > a sufficiently thorough failure might make some
> > of the disks unreachable).
>
> True until reboot, as in 2.4
See above...
> > o Cluster nodes should ideally have the same name
> > for a given disk. Extra credit, though greatly
> > appreciated by anyone who has ever had to deal
> > with a cluster where different nodes have different
> > names for the same disk. ;-)
>
> That has never been true in Linux, and not in most commerical unixes,
> either. Cluster tools are used to do this mapping and most commercially
> available linux cluster tools solve this problem, so there's no need for
> the kernel to do it.
>
> A lot of these enhancements will be covered (or at least a solution will
> be facilitated) by udev. See
>
> http://marc.theaimsgroup.com/?t=105003184600001&r=1&w=2
>
> (unfortunately, the announcement thread has grown rather big).
Yes, given a plugin that used SCSI's UUID, this could work quite well.
Thanx, Paul
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:28 EST