How should media information be indexed for SMC commands?

Roger Rose roger_rose at msn.com
Wed Aug 16 16:34:48 PDT 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* "Roger Rose" <roger_rose at msn.com>
*
It sounds like what you're looking for would fit naturally as an extension 
to the Send Volume Tag command.  There are unused Send Action Code's which 
could be defined to search intrinsic media identifiers.  You might need to 
revamp the parameter list a bit, but this would avoid eating up another 
opcode.
It might be necessary to load the media into a data transfer element to 
initially read the information, but it could be tracked after that.  (This 
assumes that the data transfer element has a path for the media changer to 
access the information.  ADC would work, if appropriate scsi commands are 
available and exposed.)
The hardest part will probably be figuring out what format(s) the media 
identifiers would appear as.
-roger rose
>________________________________
>
>	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
>Ballard, Curtis C (StorageWorks)
>	Sent: Wednesday, August 16, 2006 4:18 PM
>	To: t10 at t10.org
>	Subject: How should media information be indexed for SMC
>commands?
>
>
>	I'm working on a proposal for SMC-3 to allow the library to
>return information about the media currently in the library.
>
>	In SMC-2 everything is based on element numbers and all data
>requests are indexed by an element number.
>
>	I suspect that applications don't really care about the elements
>as much as they care about the volumes in those elements.
>
>	When accessing information about media the obvious extension to
>the current behavior would be to ask for information about the volume in
>an element and index it by element number.  I feel that would work but
>it doesn't feel natural.
>
>	I've been considering having multiple ways to access information
>about a volume and making it possible to ask for information about a
>volume by a handle as well as by an element.  If the handle is used one
>of the characteristics could be "what element is this volume in."
>
>	If accessing volume information by a handle is allowed there are
>a couple of possible handles.	The obvious handle is a barcode value but
>there is very little control over barcodes and some medium changers
>allow duplicate barcodes.  There are also medium changers that don't
>have barcode support.
>
>	Most media has some form of identifier written to the media now
>and some of the media types have world wide unique identifiers so that
>identifier would be the most unique but not the most user friendly.
>
>	I'm starting to lean towards having a command with a field for
>volume identifier and then a second field for volume identifier type.
>That way an application could provide an identifier type of "element
>number" and the library would report the information for the volume in
>that element but an application could also use a media identifier or
>barcode.
>
>	Comments?
>
>	Curtis Ballard
>	Hewlett Packard
>	StorageWorks Tape Automation
>
*
* 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 mailing list