[T10] Revisiting the RMB (Removable Medium) bit definition

Ralph Weber Ralph.Weber at wdc.com
Fri Jul 31 05:44:46 PDT 2020


This is very embarrassing. I looked SAM-6 events figure and somehow totally ignored the I_T nexus loss event. I'll have to claim a "senior moment" for that one.

Since "I_T nexus loss" is mentioned over 50 times in SAM-6, there can be no denying that the topic is solidly covered in the Architecture Model.

With this brick neatly installed in the foundation, I have posted 20-082r1<http://www.t10.org/cgi-bin/ac.pl?t=d&f=20-082r1.pdf> to reflect the sum of the detailed corrections discussed on this thread. Enjoy!

Thanks to Curtis Ballard and Kevin Butt for their unflagging efforts to make 20-082<http://www.t10.org/cgi-bin/ac.pl?t=d&f=20-082.pdf> a best-in-class proposal.

All the best, .Ralph

From: Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com>
Sent: Thursday, July 30, 2020 3:49 PM
To: Ralph Weber <Ralph.Weber at wdc.com>; t10 at t10.org
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.

Why isn't an I_T nexus removal equivalent to an I_T nexus loss?

I can't think of any SAM term about establishing an I_T nexus but it does talk about I_T nexuses going away as an I_T nexus loss.

Curtis Ballard
Hewlett Packard Enterprise
HPE Storage R&D
Fort Collins, CO
(970) 898-3013

From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> [mailto:t10-bounces at t10.org] On Behalf Of Ralph Weber
Sent: Thursday, July 30, 2020 2:13 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

Kevin,

The problem is that SAM has little, if any, idea of I_T nexuses coming or going. I_T nexuses simply are there (most of the time).

There is the I_T NEXUS RESET task management function, but it's not about vaporizing an I_T nexus.

In the Events Model, there is a Power On, but that's about things starting. There is Power Loss Expected, but that is not associated with a guarantee of power being lost.

I'd like to avoid using the verb "to remove" relative to I_T nexuses, so that "to remove" can be associated solely with the medium.

Probably, I should leave "breaking" and let CAP Zen it's way to a widely agreeable replacement.

All the best, .Ralph

From: Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>
Sent: Thursday, July 30, 2020 2:08 PM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.

Ralph,

This looks good to me. I am still trying to wrap my head around "break the I_T nexus" since this is the first use in SPC or SAM. However, I think the standard English meaning works well here.

Kevin D. Butt
SCSI Architect, Tape Firmware, Data Retention Infrastructure
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>

=========== Interesting Links ===========
[ IBM Tape Storage ]  https://www.ibm.com/it-infrastructure/storage/tape
[ SSIC - HBA/OS/Switch/Product interoperation ] https://www-304.ibm.com/systems/support/storage/ssic/interoperability.wss
[ LTO & 3592 ISV Support Matrix ] www.ibm.com/systems/resources/lto_isv_matrix.pdf<http://www.ibm.com/systems/resources/lto_isv_matrix.pdf>
[ LTO SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003556
[ 3592 SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003248
===================================



From:        Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
To:        "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Date:        07/30/2020 11:59
Subject:        [EXTERNAL] Re: [T10] Revisiting the RMB (Removable Medium) bit definition
Sent by:        t10-bounces at t10.org<mailto:t10-bounces at t10.org>
________________________________


Kevin,



This doesn't look too difficult to solve.



A removable medium (rmb) bit set to zero indicates that the medium is not removable or is able to be removed only if that removal is accompanied by the breaking of the I_T nexus connection between the application client to the device server.  A rmb bit set to one indicates that the medium is removableable to be removed without affecting the I_T nexus between the application client and the device server.



All the best, .Ralph





From:Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>
Sent: Thursday, July 30, 2020 10:42 AM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition



CAUTION:This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.



Ralph,

That does solve the mentioned problems. It does, however, cause a nuanced change in meaning from "not removable" to "able to be removed only if". The original definition says if the RMB bit is zero the medium is not removable whereas the new definition says the medium can actually be removed, but only if the device server goes away with it. While that does seem to be the intent of this effort, I have to wonder if it is not actually changing the meaning.

My concern is rooted in making sure we don't break something else. From tape devices, I do not see the proposed definition to be an issue. However, I don't have much a view into the application client side of things outside the tape world. Do application clients expect that the medium is never removed is the RMB bit is set to zero? If the I_T nexus is broken, do they search other I_T nexuses to try and find the medium?

Thanks,

Kevin D. Butt
SCSI Architect, Tape Firmware, Data Retention Infrastructure
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>

=========== Interesting Links ===========
[ IBM Tape Storage ]  https://www.ibm.com/it-infrastructure/storage/tape
[ SSIC - HBA/OS/Switch/Product interoperation ] https://www-304.ibm.com/systems/support/storage/ssic/interoperability.wss
[ LTO & 3592 ISV Support Matrix ] www.ibm.com/systems/resources/lto_isv_matrix.pdf<http://www.ibm.com/systems/resources/lto_isv_matrix.pdf>
[ LTO SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003556
[ 3592 SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003248
===================================



From:        Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
To:        "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Date:        07/30/2020 04:35
Subject:        [EXTERNAL] Re: [T10] Revisiting the RMB (Removable Medium) bit definition
Sent by:        t10-bounces at t10.org<mailto:t10-bounces at t10.org>

________________________________



Kevin,

Having slept on the problem, it's become apparent that symmetry requires the addition of "is not able to be" to the first sentence, a la...

A removable medium (rmb) bit set to zero indicates that the medium is not removableable to be removed only if that removal is accompanied by the breaking of the I_T nexus connection between the application client to the device server.  A rmb bit set to one indicates that the medium is removableable to be removed without affecting the I_T nexus between the application client and the device server.



All the best, .Ralph



From:John Geldman <John.Geldman at kioxia.com<mailto:John.Geldman at kioxia.com>>
Sent: Thursday, July 30, 2020 12:37 AM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>; t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition



CAUTION:This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.



Ralph,



I seem to be missing something.



>From my world view RMB was/is about removable media, not removable devices. We still want it to be. If we declare that rmb set to zero means not able to remove the media, then to remove the media, the device server has to be removed, i.e., disconnected.



The statement that removal of a device breaks the connection to the host needs to be said?



Isn't the problem folks thinking RMB was/is about removable devices?



John



From:t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ralph Weber
Sent: Wednesday, July 29, 2020 6:45 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition



IMHO The absence of any statement about the I_T nexus in the RMB=0 case severely limits the value of the change.



From:John Geldman <John.Geldman at kioxia.com<mailto:John.Geldman at kioxia.com>>
Sent: Wednesday, July 29, 2020 8:27 PM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>; t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition



CAUTION:This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.



The observations are all correct, but they do obfuscate. Does this work?



A removable medium (rmb) bit set to zero indicates that the medium is not removable able to be removed from the device server. A rmb bit set to one indicates that the medium is removableable to be removed from the device server. If the rmb bit is set to one and the medium is removed, then the I_T nexus between the application client and the device server, if any, is not affected.



John



From:t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ralph Weber
Sent: Wednesday, July 29, 2020 5:52 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition



I agree that the two sentence are not symmetrical, however... I cannot find a way to make them symmetrical that does not involve an excess of Rube Goldberg English that obfuscates more than it clarifies.



Please feel free to augment the suggestion made below with detailed text changes.



All the best, .Ralph



From:Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>
Sent: Wednesday, July 29, 2020 3:42 PM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition



CAUTION:This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.



That is starting to look good to me, but I would suggest making it symmetrical.

A removable medium (rmb) bit set to zero indicates that the medium is not removable able to be removed without removing the I_T nexus that connects the application client to the device server.  A rmb bit set to one indicates that the medium is removableable to be removed without affecting the I_T nexus between the application client and the device server.


Kevin D. Butt
SCSI Architect, Tape Firmware, Data Retention Infrastructure
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>

=========== Interesting Links ===========
[ IBM Tape Storage ]  https://www.ibm.com/it-infrastructure/storage/tape
[ SSIC - HBA/OS/Switch/Product interoperation ] https://www-304.ibm.com/systems/support/storage/ssic/interoperability.wss
[ LTO & 3592 ISV Support Matrix ] www.ibm.com/systems/resources/lto_isv_matrix.pdf<http://www.ibm.com/systems/resources/lto_isv_matrix.pdf>
[ LTO SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003556
[ 3592 SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003248
===================================



From:        Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
To:        "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Date:        07/29/2020 13:20
Subject:        [EXTERNAL] Re: [T10] Revisiting the RMB (Removable Medium) bit definition
Sent by:        t10-bounces at t10.org<mailto:t10-bounces at t10.org>

________________________________



Or... how about something along the lines of:

A removable medium (rmb) bit set to zero indicates that the medium is not removable without removing the I_T nexus that connects the application client to the device server.  A rmb bit set to one indicates that the medium is removableable to be removed without affecting the I_T nexus between the application client and the device server.





From:Curtis Stevens <curtis.stevens at seagate.com<mailto:curtis.stevens at seagate.com>>
Sent: Wednesday, July 29, 2020 3:12 PM
To: Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com>>; Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>; Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition



CAUTION:This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.



I think part of the blatant wording that Ralph is proposing is that those making the requirements on the device side do not fully understand SCSI.  This has been the case from day 1 and has not changed.  It is fairly easy to understand commands and what they do.  Understanding the architecture is a different story.



I think your suggested change could be integrated with Ralphs change...





---------------------------------------------

Curtis E. Stevens

Technologist

Seagate Technology



E-Mail: Curtis.Stevens at Seagate.com<mailto:Curtis.Stevens at Seagate.com>

Phone: 949-307-5050



________________________________

From:Ballard, Curtis C (HPE Storage) <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com>>
Sent: Wednesday, July 29, 2020 12:49 PM
To: Curtis Stevens <curtis.stevens at seagate.com<mailto:curtis.stevens at seagate.com>>; Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>; Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org><t10 at t10.org<mailto:t10 at t10.org>>
Subject: RE: [T10] Revisiting the RMB (Removable Medium) bit definition



Why don't we specify it in architectural terms.  Something along the lines of:

A removable medium (rmb) bit set to zero indicates that the medium is not removable from the device server.

A rmb bit set to one indicates that the medium is removableable to be removed without removing the device server.



Curtis Ballard

Hewlett Packard Enterprise

HPE Storage R&D

Fort Collins, CO

(970) 898-3013



From:t10-bounces at t10.org<mailto:t10-bounces at t10.org>[mailto:t10-bounces at t10.org] On Behalf Of Curtis Stevens
Sent: Wednesday, July 29, 2020 1:04 PM
To: Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>; Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition



I would turn the proposal around and say the RMB bit shall only be set to one if the device is able to report ... after is media is ejected.





---------------------------------------------

Curtis E. Stevens

Technologist

Seagate Technology



E-Mail: Curtis.Stevens at Seagate.com<mailto:Curtis.Stevens at Seagate.com>

Phone: 949-307-5050



________________________________

From:t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>> on behalf of Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>
Sent: Wednesday, July 29, 2020 8:48 AM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org><t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition



Ralph,

I applaud your goal, however, I am concerned about this definition. Take, for example, a tape library. It has removable media, yet it would not report one of these two additional sense codes. Even if all user cartridges were removed, the library would still be ready. It could do management type things including using diagnostic cartridges (not seen as medium to the application client) to test drives.

The RMBshould be set to zero, if the device server is not able to terminate a TEST UNIT READY command (6.48) with CHECK CONDITION status, with the sense key set to NOT READY and the additional sense code:
a)set to NOT READY, MEDIUM NOT PRESENT; or
b)having the ADDITIONALSENSECODEfield (see 4.4.2 and 4.4.3) set to 3Ah (e.g., MEDIUM NOT PRESENT - TRAY OPEN).

Thanks,

Kevin D. Butt
SCSI Architect, Tape Firmware, Data Retention Infrastructure
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>

=========== Interesting Links ===========
[ IBM Tape Storage ]  https://www.ibm.com/it-infrastructure/storage/tape
[ SSIC - HBA/OS/Switch/Product interoperation ] https://www-304.ibm.com/systems/support/storage/ssic/interoperability.wss
[ LTO & 3592 ISV Support Matrix ] www.ibm.com/systems/resources/lto_isv_matrix.pdf<http://www.ibm.com/systems/resources/lto_isv_matrix.pdf>
[ LTO SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003556
[ 3592 SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003248
===================================



From:        Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
To:        "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Date:        07/29/2020 06:49
Subject:        [EXTERNAL] Re: [T10] Revisiting the RMB (Removable Medium) bit definition
Sent by:        t10-bounces at t10.org<mailto:t10-bounces at t10.org>

________________________________



Proposal 20-082r0<http://www.t10.org/cgi-bin/ac.pl?t=d&f=20-082r0.pdf>SPC-6: Removable Medium Bit Expectations has been posted to bring this discussion thread to the attention of CAP.

Resisting the ongoing calls to put as many words as possible into every standard, the proposal includes only one of the methods for defining a "real" removable medium device discussed in this thread. For the purposes discussed here, only one method is necessary to sufficiently define the standard.

All the best, .Ralph

From:t10-bounces at t10.org <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Michael Webster
Sent: Tuesday, July 21, 2020 7:57 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

I would like to add one other tidbit:  A device reporting RMB=1 in addition to being capable of a state that reports MEDIUM NOT PRESENT, such a device should also properly support and execute an ejection operation of that media when sent a START/STOP UNIT command with Power_Condition=0, LoEj=1, & Start=0.

Mike Webster
Western Digital

From: <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> on behalf of Mike Webster <Mike.Webster at wdc.com<mailto:Mike.Webster at wdc.com>>
Date: Friday, July 17, 2020 at 10:30 AM
To: "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

I would expect a USB memory stick to report RMB=0 and ejection causes the whole device to be removed from the operating system's driver stack.  Afterward, such an ejected device would require an unplug/re-plug for the device to respond to anything on USB.

Unless that USB memory stick included a slot for media (e.g. an SD slot) then I would expect the USB memory stick to report RMB=1 and ejection would only cause the device to remove the media, the device would remain in the operating system's driver stack, and the device would begin reporting CHECK CONDITION, NOT READY, MEDIUM NOT PRESENT for TEST UNIT READY.

Mike Webster
Western Digital

From: <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> on behalf of Curtis Stevens <curtis.stevens at seagate.com<mailto:curtis.stevens at seagate.com>>
Date: Friday, July 17, 2020 at 10:05 AM
To: Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>, Paul Suhler <Paul.Suhler at kioxia.com<mailto:Paul.Suhler at kioxia.com>>
Cc: "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>, "t10-bounces at t10.org<mailto:t10-bounces at t10.org>" <t10-bounces at t10.org<mailto:t10-bounces at t10.org>>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

We had this descussion during the original specification development.  For USB, the device controller is removed along with the media.  There is nothing present to respond with an RMB bit.  If however, you plug in a USB floppy, you can have an RMB bit that enables eject function reporting.


---------------------------------------------
Curtis E. Stevens
Technologist
Seagate Technology

E-Mail: Curtis.Stevens at Seagate.com<mailto:Curtis.Stevens at Seagate.com>
Phone: 949-307-5050

________________________________

From:t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>> on behalf of Kevin D Butt <kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>>
Sent: Friday, July 17, 2020 9:40 AM
To: Paul Suhler <Paul.Suhler at kioxia.com<mailto:Paul.Suhler at kioxia.com>>
Cc: t10 at t10.org<mailto:t10 at t10.org><t10 at t10.org<mailto:t10 at t10.org>>; t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

I concur with Curtis and Paul.

Kevin D. Butt
SCSI Architect, Tape Firmware, Data Retention Infrastructure
T10 Standards
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com<mailto:kdbutt at us.ibm.com>

=========== Interesting Links ===========
[ IBM Tape Storage ]  https://www.ibm.com/it-infrastructure/storage/tape
[ SSIC - HBA/OS/Switch/Product interoperation ] https://www-304.ibm.com/systems/support/storage/ssic/interoperability.wss
[ LTO & 3592 ISV Support Matrix ] www.ibm.com/systems/resources/lto_isv_matrix.pdf<http://www.ibm.com/systems/resources/lto_isv_matrix.pdf>
[ LTO SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003556
[ 3592 SCSI Reference ] http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003248
===================================



From:        Paul Suhler <Paul.Suhler at kioxia.com<mailto:Paul.Suhler at kioxia.com>>
To:        "Ballard, Curtis C (HPE Storage)" <curtis.ballard at hpe.com<mailto:curtis.ballard at hpe.com>>, Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>, "t10 at t10.org<mailto:t10 at t10.org>" <t10 at t10.org<mailto:t10 at t10.org>>
Date:        07/17/2020 09:19
Subject:        [EXTERNAL] Re: [T10] Revisiting the RMB (Removable Medium) bit definition
Sent by:        t10-bounces at t10.org<mailto:t10-bounces at t10.org>

________________________________



I agree with Curtis about the need to be able to report NOT READY, MEDIUM NOT PRESENT. I've worked on both SSC and SBC devices like that.

Paul
Kioxia

From:t10-bounces at t10.org <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ballard, Curtis C (HPE Storage)
Sent: Friday, July 17, 2020 9:54 AM
To: Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>; t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: [T10] Revisiting the RMB (Removable Medium) bit definition

Ralph,

That bit is used with tape drives and was used with SCSI magneto optical drives, DVD drives, etc.

Even system I've used with that bit set to one, and I've worked with several devices from different manufacturers that set that bit to one, only use it in reference to the media with no device server disruption other than the expected Unit Attention condition transitions as the media is removed and re-loaded.

SCSI devices should only set that bit to one if they are able to report an 02h/3Ah/00h - NOT READY, MEDIUM NOT PRESENT

Curtis Ballard
Hewlett Packard Enterprise

From:t10-bounces at t10.org<mailto:t10-bounces at t10.org><t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ralph Weber
Sent: Thursday, July 16, 2020 5:27 PM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: [T10] Revisiting the RMB (Removable Medium) bit definition

Regarding the Standard INQUIRY data RMB bit, SPC-6 r02 says...
"A removable medium (RMB) bit set to zero indicates that the medium is not removable. A RMB bit set to one indicates that the medium is removable."

An interesting debate has developed regarding whether a USB "memory stick" is an RMB=0 or an RMB=1 device.

One wag has suggested that the RMB bit definition be conditionalized on the presence/absence of a coincident Logical Unit Reset condition or I_T Nexus Loss condition, something along the lines of...
"A removable medium (RMB) bit set to zero indicates that the medium is not removable without resulting in a Logical Unit Reset condition (see SAM-6) or an I_T Nexus Loss condition (see SAM-6). A RMB bit set to one indicates that the medium is removable with no concurrent Logical Unit Reset condition or I_T Nexus Loss condition."

How says the T10 body politic?

Thanks,

.Ralph_______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://www.t10.org/mailman/listinfo/t10

_______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://www.t10.org/mailman/listinfo/t10

 _______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://www.t10.org/mailman/listinfo/t10

 _______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://www.t10.org/mailman/listinfo/t10

 _______________________________________________
T10 mailing list
T10 at t10.org<mailto:T10 at t10.org>
https://www.t10.org/mailman/listinfo/t10

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20200731/e829f58a/attachment-0001.html>


More information about the T10 mailing list