dance of the media serial numbers (using LOG SENSE)

Robert Snively rsnively at brocade.com
Thu Oct 31 12:16:03 PST 2002


* From the T10 Reflector (t10 at t10.org), posted by:
* Robert Snively <rsnively at brocade.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2811A.55EA5AB0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To the best of my knowledge, this is all managed already=20
for all kinds of devices using the READ ATTRIBUTE and=20
WRITE ATTRIBUTE commands.  Those functions were designed=20
to read media serial numbers from whatever kind of medium=20
was defined, including tape cartridges and presumably=20
CDs and DVDs.  I believe that this would be a far=20
more practical and compliant mechanism for recovering=20
(and if necessary, writing) such information.  See SPC-3=20
clause 5.10 and related areas.  The writing of such=20
information might even allow writing authorization and=20
machine origin codes.=20

ATAPI drives may have other commands associated with=20
CD and DVD commands designed to read special non-data=20
areas of the device, but I have not followed that area closely.=20

Bob=20

> -----Original Message-----=20
> From: Rob Haydt [ mailto:robhay at windows.microsoft.com
 ]=20
> Sent: Tuesday, October 29, 2002 11:20 AM=20
> To: t10 at t10.org=20
> Cc: Emily Hill=20
> Subject: dance of the media serial numbers (using LOG SENSE)=20
>=20
>=20
> * From the T10 Reflector (t10 at t10.org), posted by:=20
> * "Rob Haydt" <robhay at windows.microsoft.com>=20
> *=20
> At the last t10 meeting, we were instructed to investigate=20
> the LOG SENSE (section 7.6) command for retrieving media=20
> serial numbers. Apparently, tape vendors do this sort of=20
> thing "all the time" (is this true?). After some internal=20
> discussion, this would seem to meet our needs.=20
>  =20
> As I read SPC3, implementing LOG SENSE doesn't require=20
> implementing any other command (like LOG SELECT, section=20
> 7.5). A new section will need to be added to LOG PARAMETERS=20
> (section 8.2) for the retrieving media serial numbers. It=20
> would probably be good to specify that serial number related=20
> parameters MAY NOT be set or modified using LOG SENSE or LOG=20
> SELECT. Interaction with devices that already implement LOG=20
> SENSE/SELECT is also an area of concern.=20
>  =20
> The questions that come to mind are:=20
>  =20
> 1. Is it correct that LOG SENSE can be implemented without=20
> implementing LOG SELECT?=20
> 2. Would implementing LOG SENSE be inappropriate or extremely=20
> difficult for ATAPI devices?=20
> 3. Will existing ATAPI devices break if they receive a LOG=20
> SENSE command?=20
> 4. Will existing LOG SENSE/SELECT implementations break if we=20
> add the media serial number support there?=20
> 5. Is there some compelling reason to take a simpler approach?=20
>=20
> Yet another media serial number proposal will be forthcoming shortly, =

> -rob=20
>=20
> *=20
> * For T10 Reflector information, send a message with=20
> * 'info t10' (no quotes) in the message body to majordomo at t10.org=20
>=20


------_=_NextPart_001_01C2811A.55EA5AB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

RE: dance of the media serial numbers (using LOG SENSE) To the best of my knowledge, this is all managed = already 
for all kinds of devices using the READ ATTRIBUTE = and 
WRITE ATTRIBUTE commands.  Those functions were = designed 
to read media serial numbers from whatever kind of = medium 
was defined, including tape cartridges and = presumably 
CDs and DVDs.  I believe that this would be a = far 
more practical and compliant mechanism for = recovering 
(and if necessary, writing) such information.  = See SPC-3 
clause 5.10 and related areas.  The writing of = such 
information might even allow writing authorization = and 
machine origin codes. ATAPI drives may have other commands associated = with 
CD and DVD commands designed to read special = non-data 
areas of the device, but I have not followed that = area closely. Bob > -----Original Message----- 
> From: Rob Haydt [mailto:robhay at windows.micro= soft.com] 
> Sent: Tuesday, October 29, 2002 11:20 AM 
> To: t10 at t10.org 
> Cc: Emily Hill 
> Subject: dance of the media serial numbers = (using LOG SENSE) 
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted = by: 
> * ;Rob Haydt; = <robhay at windows.microsoft.com> 
> * 
> At the last t10 meeting, we were instructed to = investigate 
> the LOG SENSE (section 7.6) command for = retrieving media 
> serial numbers. Apparently, tape vendors do = this sort of 
> thing ;all the time; (is this true?). = After some internal 
> discussion, this would seem to meet our = needs. 
> =A0 
> As I read SPC3, implementing LOG SENSE doesn't = require 
> implementing any other command (like LOG = SELECT, section 
> 7.5). A new section will need to be added to = LOG PARAMETERS 
> (section 8.2) for the retrieving media serial = numbers. It 
> would probably be good to specify that serial = number related 
> parameters MAY NOT be set or modified using LOG = SENSE or LOG 
> SELECT. Interaction with devices that already = implement LOG 
> SENSE/SELECT is also an area of concern. 
> =A0 
> The questions that come to mind are: 
> =A0 
> 1. Is it correct that LOG SENSE can be = implemented without 
> implementing LOG SELECT? 
> 2. Would implementing LOG SENSE be = inappropriate or extremely 
> difficult for ATAPI devices? 
> 3. Will existing ATAPI devices break if they = receive a LOG 
> SENSE command? 
> 4. Will existing LOG SENSE/SELECT = implementations break if we 
> add the media serial number support there? = 
> 5. Is there some compelling reason to take a = simpler approach? 
> 
> Yet another media serial number proposal will = be forthcoming shortly, 
> -rob 
> 
> * 
> * For T10 Reflector information, send a message = with 
> * 'info t10' (no quotes) in the message body to = majordomo at t10.org 
> 
------_=_NextPart_001_01C2811A.55EA5AB0--




More information about the T10 mailing list