I suspect that all implementers have
only one set of SMC tapealerts and that they get cleared when the first
initiator reads them. I have not checked our implementation, but
this is my guess since there is no way to communicate I_T nexus to the
SMC device.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com
http://www-03.ibm.com/servers/storage/
"Rose, Roger"
<Rrose@tandbergdata.com> Sent by: owner-t10@t10.org
12/19/2007 05:00 PM
To
<t10@t10.org>, <GBarton@overlandstorage.com>
cc
Subject
RE: ADI - SMC tape alerts using ADI
bridging (re proposal 06-420r2 and smc3r09)
Geoffrey,
I suppose I may be confused on
which set of tape alerts. (I tend to be confused fairly easily.)
I haven't run tests on this either,
but I doubt whether any ADI Bridge drives cache the Library Log Sense data
to allow per-initiator clearing. There currently isn't any obvious
mechanism to indicate that the Log Sense data has changed and the cache
needs refreshed.
The technique you've described
to pass the command through and update the cache might be workable. It
appears to have an odd corner case:
If the Remote SMC Device Server
clears Tape Alert bits upon sending them to the bridge, then upon
the next retrieval the bridge won't be able to tell whether (a) the bits
are still cleared from the last retrieval or (b) the underlying condition
has been cleared (e.g. by performing the specified corrective action) and
shouldn't be reported to other initiators anymore.
If the Remote SMC Device Server
doesn't clear Tape Alert bits upon sending them to the bridge, then
upon the next retrieval the bridge won't be able to tell whether (a) the
condition persists and should not be reported again to initiators that
have already seen it or (b) the underlying condition was cleared and has
actually occurred again.
I suspect that supporting per-initiator
Tape Alert would require adding another flag to Notify data Transfer Device
or something along those lines.
-roger rose
Product Test, Tandberg Data
From: GBarton@overlandstorage.com
[mailto:GBarton@overlandstorage.com]
Sent: Wednesday, December 19, 2007 3:57 PM
To: t10@t10.org
Cc: Rose, Roger
Subject: RE: ADI - SMC tape alerts using ADI bridging (re proposal
06-420r2 and smc3r09)
roger,
I think what you are talking about is the TapeAlert for the DT device (tape
drive) as specified in ssc2 that the library can use to track and/or report
problems in it's tape drives. I am talking about the library TapAlerts
defined in smc2 and currently smc3 and referred to in proposal 06-420r2.
Currently, log page 12h TapeAlert Response Log Page is not currently specified
in smc2 or smc3. Rather, log page 2Eh TapeAlert Log Page. If the host access
to the library is through the ADI bridge, the host (or hosts) can request
log page 2Eh. There is currently no mechanism using ADI bridging to clear
the flags at the library on a per I-T nexus basis, since the library has
no visibility of the initiator. The DT device (tape drive) can keep track
of which initiators have requested page 2Eh, but there is no mechanism
to keep the tape drive up to date on current tape alerts set, unless the
DT device passes the log sense command through the bridge (which will clear
the flags in the library) and intercepts the log page and updates cached
values accordingly. Is this being done by tape drives? I have not run an
experiment to find out.
Geoffrey L. Barton
Overland Storage
4820 Overland Ave.
San Diego, CA 92123
858 974-4586
gbarton@overlandstorage.com
"Rose, Roger"
<Rrose@tandbergdata.com>
12/19/2007 02:21 PM
To
<GBarton@overlandstorage.com>,
<t10@t10.org>
cc
Subject
RE: ADI - SMC tape alerts using ADI
bridging (re proposal 06-420r2 and smc3r09)
This is currently covered by ADC section 4.2.6 and ADC-2 Rev 8 section
4.6.
>From ADC-2:
4.6 TapeAlert application client interface
The ADC device server supports a modified version of TapeAlert specified
in SSC-2. As supported by the ADC device server, the TapeAlert flags represent
states, and the state flags are not set to zero upon retrieval of the TapeAlert
Response log page (see 6.1.3). Instead, the state flags are set to zero
upon a change of the condition involved with the state (see table 5).
-roger rose
Product Test, Tandberg Data
From: owner-t10@t10.org [mailto:owner-t10@t10.org]
On Behalf Of GBarton@overlandstorage.com
Sent: Tuesday, December 18, 2007 3:07 PM
To: curtis.ballard@hp.com; michael_banther@hp.com; kdbutt@us.ibm.com;
halvard.eriksen@tandbergstorage.com; PayneR@iomega.com; Paul.Stone@Quantum.com;
paul.suhler@Quantum.com
Cc: t10@t10.org
Subject: ADI - SMC tape alerts using ADI bridging (re proposal 06-420r2
and smc3r09)
In reviewing Michael Banther's proposal for tape alert flag (06-420r2),
it occurred to me that there is a problem with SMC tape alerts in general
if ADI bridging is being used for host access to the library.
smc3r09 clause 5.2.2 third paragraph defines deactivations for tape alerts.
Numbered list 1) states "after the
TapeAlert log page is read. The TapeAlert flags shall be deactivated on
a per-initiator basis such that active flags are available for other initiators;
".
and in proposal 06-420r2 clause 5.4.4 last paragraph, the same statement
is made with "should" instead of "shall".
Since a library device using ADI bridging is not aware of initiators, the
library cannot clear the flags on a per initiator basis. Does this mean
the DT device must cache the tape alert log page and keep track of the
reads of that log page? If so, how does the DT device know when to cache
a new page? And if the DT device handles the tape alert log page on a per
initiator basis, how does the library know when to clear the flags? As
far as I can tell, there is no mechanism to handle this.
Even if proposal 06-420r2 is not incorporated into smc3, the problem still
exists.
regards,
Geoffrey L. Barton
Overland Storage
----------------------------------------------------
Tiered Data Protection Made Simple
http://www.overlandstorage.com/
----------------------------------------------------