Clearing effects of logouts on different protocols
rsnively at Brocade.COM
Wed Mar 6 14:17:51 PST 2002
* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
> Folks, fortunately, this is addressed by the recommended
> treatment of MODE SELECT established parameters in
> tape drives. While "saved" parameters are recommended,
> implicit default parameters established by the
> state information about the tape (including position,
> compression parameters, and presumably partition
> information) should now be required.
What is the "recommended treatment"? Did I miss a proposal? What is an
"implicit default" parameter? If I am reading FCP-2 rev 7a correctly, table
4 mandates that a PLOGI will require "Target mode page parameters restored
|from saved pages (when saved pages are supported, or default mode page
parameters when saved pages are not supported)". Granted, this is the case
"Only for initiator port associated with the action", but some mode
parameters are inherently device-wide.
To outline one of the problem scenarios once again, an initiator A may be
happily writing to my partition 2. He may have navigated to partition 2 by
means of a MODE SELECT, but he may have navigated there by means of a
LOCATE. Initiator B may thereby boot. As 'hosts' are wont to do, initiator B
does a PLOGI to me. This causes saved mode page parameters to be restored,
as mandated by FCP-2 rev 7a, table 4. The saved mode page parameters may
specify some other partition (let's assume 0). The tape repositions to BOP
0. Initiator A issues a subsequent WRITE command, assuming that the current
position has not been altered. This subsequent WRITE ends up writing over
Partition 0, LBA 0. Data loss has occurred. Note that this cannot be
eliminated by means of reservations - classic or persistent.
The above scenario is only one of many where data loss may occur, due to the
clearing effects of link related functions. I believe that even DASD devices
are not immune. What about the rigid disk device geometry page?
See SSC-2 clause 8.3.1:
"The device-specific parameters contained in the
mode parameter header, mode block descriptor values,
and Data Compression mode page shall be retained
following a reset condition (e.g., Target Reset,
SCSI Logical Unit Reset, Fibre Channel Reset LIP or PLOGI).
NOTE 44 This is to facilitate continued operation
for applications such as backup/restore following
a reset event."
"f) following a reset condition occurring while ready,
the device server shall retain knowledge of the density
code as determined by items B) through D) above."
> >More fundamentally, there exists an architectural layering
> >issue. Why should activities at the port layer effect
> >changes at the logical unit layer? I contend that this
> >is an encapsulation issue, violating commonly accepted
> >layering principles.
> There is a lot of discussion that can be had about this.
Perhaps that discussion *should* be had. While I may have missed some
relevant discussion, I do not recall any argument being advanced to state
that the clearing effects of 'port level stuff' upon 'logical unit level
stuff' is A Good Thing.
Interestingly, PRLI was granted specific exemptions in FCP-2 regarding these
effects (table 6). At some point, someone must have considered the negative
aspects of these effects upon the logical unit layer. To not grant the same
exemptions to PLOGI seems counter-intuitive at best.
Basically, the approach that has been taken in most
of the protocols is to replicate the behavior that generic
driver software would see for corresponding physical changes
(configuration, device installation, etc.) for
SCSI-2/SPI-x compliant devices in the new protocols.
The network management (including the definition of
nodes, discovery of topology, and most other functions)
is viewed as orthogonal to the SCSI operations. Once
a configuration is established by network management,
normal SCSI operation is expected. Another way to phrase
this is to say that SCSI login operations are NOT part
of SCSI operation, since SPI-x compliant devices and their
supporting software are unaware of such behaviors.
The layering was essentially at the CAM level. This
preserves present software as much as possible. However,
some present software is not very good at handling
multiple initiator environments, whether networked or not,
and therefore continues to use legacy reservations and
to issue device resets. Other implementations are quite
good at handling this and use persistent reservations for
everything from device protection to cluster quorum management.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10