Removability

Devon Worrell worrell at dt.wdc.com
Wed Feb 4 20:11:46 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* Devon Worrell <worrell at dt.wdc.com>
*
Hi,

Just a couple of quick comments.

>An INQUIRY command should return the current device capabilities based on the media
>inserted. Even if the device is capable of various formats, capacities, etc. As an
>example, a DVD-RAM could read a CD-ROM, but not format or write it. Lockability
>would be device, media, and thus vendor specific.

INQUIRY should not be affected by the media. There would be no
easy way for the Host to know when to get the correct information.

I think that the GET CONFIGURATION command that is currently part
of MtFuji and SPC-2 would be a much better method.


>Four new bits for removable storage devices:
>Readable, Writeable, Formattable, Lockable (RWFL)

These are handled by the GET CONFIGURATION command and already indicate
to the Host what the device is capable of and also allows changes for
the media alond with notification techniques. About the only thing that
is not covered well today is the Lockable "Feature".

>Having the 3 bits DPO, FUA, RelAddr, all set to 0 for READ is very good.
>What would it take to change the Transfer Length from 2 bytes to 3 bytes for these
>commands? This allows 8 GB transfers for future growth.

The use of the FUA is important, but yes the other bits should be zero.
As for the length there is the READ (12) command. This is currently
mandatory for DVD (Fuji).

>Pressing the eject button forces the device to enter 'button-pressed state.This state can
>only be exited with approval from the host, not on release of the button, nor on repeated
>press then release of the button. Actual ejection of media should be governed by the host.
>The eject button is a 'request to eject' rather than a command to eject. UNSOLICITED
>STATUS appears to be the best option for host notification.

This control function is controlled by a new feature in MtFuji called
Persistent Prevent. This mechanism sends notifications and allows the
host to eject the media only, once it has been reported to the host
as available. This is a superset of the MSN capability.






At 3:21 PM -0700 1/27/98, DARRELL REDFORD wrote:
>* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
>* DARRELL REDFORD <REDFORDD at IOMEGA.COM>
>*
>The file attached has some additional proposals for the committee. 
>
>Iomega is addressing removability commands and concepts for a
>simplified implementation.  Please read and give feedback.  
>
>RBC_IOM is in  Word 7, PDF, and RTF.  Hopefully this will allow everyone
>to read their preferred format.
>
>Thank you.
>
>Darrell Redford
>R&D Evangelist
>Iomega Corporation
>801-778-4432
>801-725-1502 cell
>redfordd at iomega.com

Devon,

   _/_/_/_/    _/_/_/_/    _/      _/ | Devon B. Worrell <worrell at dt.wdc.com>
  _/      _/  _/      _/  _/      _/  | Senior Staff Engineer
 _/      _/  _/_/_/_/    _/  _/  _/   | Interface Technology
_/      _/  _/       _/ _/_/_/_/_/    | Western Digital Corporation
/_/_/_/    _/_/_/_/_/  _/      _/     | 8105 Irvine Center Dr
				      | Irvine CA, 92618
				      | Ph: (714) 932-7042 Fax: (714) 932-8806

"Every truth passes through three stages before it is recognized. In the first it is
 ridiculed, in the second it is opposed, in the third it is regarded as self-evident!"

"Not speaking in an official capacity for my employer"

PGP Key Fingerprint = 4D37 E5B5 45FD 66DB 9DDB  1785 F060 6662 E5BA D357



*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list