Messages in this thread | | | Subject | Re: [patch for playing] Patch to support 4000 disks and maintain backward compatibility | From | Paul McKenney <> | Date | Sun, 13 Apr 2003 06:59:25 -0700 |
| |
> 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/
| |