> 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:14 EST