Matt, nice to hear from you again ;)
Richard, I didn't intent to agrivate you I just want to clarify some
things. Here at Sun we do *LOTS* of stuff to make sure that our own
dynamic nature doesn't screw us over. We have a lot of sys-admins who get
very upset when a system reboots and it can find it's drives because they
have changed target id's.
I am also (here at Sun) pushing to make sure we have this same reliability
on drives in a SAN that we haven't had a chance to label.
Rodger Wilson
Target and SCSI Drivers (Sun Microsystems, Inc.)
DIRECT: (303) 272-8252 HOME: (303) 499-9498
FAX: (303) 272-7793 CELL: (303) 669-7955
PAGER: (303) 203-8561 EMAIL: Rodger.Wilson@sun.com
On Thu, 27 Apr 2000, Matthew Jacob wrote:
>
>
> > Rodger Wilson writes:
> > > It seems to me that there are two types of persistence:
> > >
> > > a) real time reconfiguration (via lips, etc)
> > >
> > > Right now I only fibre channel has this problem. That is the problem of
> > > device changing their target (APLA) change while still running. These,
> > > devices should be refered to by their WWN while in the frame work, and
> > > then having the HBA change the WWN into an ALPA just before send the
> > > CDB. This can be done with a simple lookup table within a HBA.
> >
> > Jargon alert! I have no idea what you're saying.
>
> Rodger is referring to the fact that a device can change it's local Arbitrated
> Loop Physical Address due to a LIP (loop initialization- happens when you plug
> something into the loop).
>
> I tend to think that this is less of an issue than Rodger does. It's pretty
> easy to make sure a driver keeps local addressing persistent while running.
>
> That is, there is a direct relationship to an AL_PA and a loop id (target 0 is
> AL_PA 0xef, target 1 is 0xe8) and so on. You start out with 'target ids' (if
> your system addressing schema requires 'targets') having a 1-1 correspondence.
> As the running loop is disturbed and things shift around, you can keep the
> targets persistent whilst the loopid shift underneath.
>
> At any rate, the point here is that the actual physical route and location
> addressing of devices can't be assumed to be static while running. What is
> static (or should be :-) are properties like WWN, or VPD Info like drive
> serial number.
>
> >
> > > b) rebooting persistence.
> > >
> > > Here we want a computer to talk to the same device after having been
> > > rebooted. For devices like IDE & SCSI the issue is fairly easy, we
> > > simply want a path to represent name like disk0. But in FC we need
> > > a name to be associated with a framework path and a paticular disk
> > > drive. This can be handled with in the /etc/devfsd.conf
> >
> > Jargon again. "Framework path"?
>
> I think this is a Sun term.
>
>
> >
> > > /etc/devfsd.conf
> > >
> > >
> > > /dev/discs/disc0 /dev/ide/hd/c0b0t0u0
> > > /dev/discs/disc1 /dev/scsi/host1/bus2/t3,4
> > > /dev/discs/disc2 /dev/fc/host1/bus3/wwn2100002037265f98,0
> > >
> > > Then when the system loads it creates these links & nodes even if
> > > the drive is missing, then if io goes down to the HBA for a target
> > > the HBA can look up the WWN and send io to the target if it is found
> > > else return error. This would allow for persistence even if the
> > > drive was not available untill 5 mins after reboot.
>
> I think the idea of binding to UUIDs, WWNs, VPD Info or drive labels is a good
> thing.
>
> -matt
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:15 EST