RBC removable questions

John Nels Fuller jfuller at microsoft.com
Fri Jan 23 15:31:56 PST 1998


* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* John Nels Fuller <jfuller at MICROSOFT.com>
*
Comments below:

> -----Original Message-----
> From:	Mike_N_Bryan at notes.seagate.com [SMTP:Mike_N_Bryan at notes.seagate.com]
> Sent:	Friday, January 23, 1998 1:46 PM
> To:	t10 at Symbios.COM
> Subject:	RBC removable questions
> 
	<<snip>>
>  -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> --
> -- -- -- -- -- --
> Pat
> Op 2Ah Write
>  I love the DPO = RelAdr = 0 simplification.
>  I love the FUA = 0 simplification of 28h Read.
>  Why don't we require FUA = 0 for 2Ah Write as well?
> Mike
> In order to insure that write data is not cached, it is necessary
> to use the FUA bit. This is a requirement in several cases: pending
> removal of Device Bay drives is a prime example. The Synchronize Cache
> command doesn't prevent writes from being cached. It only forces
> cached writes to be written to the media.
> Pat
> Ah, I think I now understand the concern - but then I ask ...
> Why not require the host to disable write-cacheing in the mode page?
> Why supply the temporary disable of a FUA bit?
> 
> >> Mike's reply -
> What you suggest is possible, but would require additional Mode Select
> commands to turn WCD on and off. The use of the FUA bit should be
> expounded upon by John Fuller of Microsoft.
> 
	[JNF]  Turning the cache off and then back on to do a single
transfer doesn't make sense as it would require that the command stream be
executed in order.  What we really use FUA for is to do an occasional
transfer of critical data that we must insist on getting onto the media.
This feature is primarily used by SQL Server to ensure that the media always
has a valid structure where a transaction is either all in or all out.  On
the other hand the Synchronize Cache will be used when we dismount a drive
to prepare it for removal, at that time we know we won't be issuing any more
writes.

> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- -- -- -- -- --
	<<snip>>
> Pat
> When does a change in this mode page cause a Unit Attention (ASC = 2Ah
> Mode
>  Param's
> Changed)?
> Mike
> Mode Parameters Changed is only valid if more than one initiator is logged
> into a drive. If one
> initiator changes values that will affect another initiator, like the
> logical capacity, Mode
> Parameters Changed will have to be sent to the other initiator. If
> Microsoft supports it, we
> would like to send Unsolicited Status to the idle initiator. If Microsoft
> doesn't support
> unsolicited status, then Mode Parms Changed would have to be returned in
> the next command
> status.
> 
	[JNF]  For the foreseeable future, Microsoft will not be taking
advantage of multiple initiator drives; that is to say that we will log into
those drives with the "exclusive" bit set.  Therefore an Unsolicited Status
for Mode Param's Changed won't happen regardless of how the notification is
handled.  We do, however, like the idea of Unsolicited Status and by the
time we are able to take advantage of multiple initiator drives we will be
able to support it.

> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> -- -- -- -- -- --
	<<snip>> 
*
* 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