This message is from the T13 list server.
Dan,
I'm getting two copies of everything I'm going crazy with all this
e-mail please fix....
Thanks
Marc
Thomas Colligan <[EMAIL PROTECTED]>@t13.org on 03/12/2002 03:20:48 PM
Sent by: [EMAIL PROTECTED]
To: "McGrath, Jim" <[EMAIL PROTECTED]>, "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
cc:
Subject: Re: [t13] but already we did drop Read/Write Long
This message is from the T13 list server.
I suspect that this may be incorrect. If I have an OEM that utilizes the
removed commands for their own purposes and all their suppliers support the
removed commands. What is being stated here is, as we approach the 137Gb
boundary you are telling them sorry, you can't do that any more and we have
no new solution for you. Then who is T13 listening to. Is there an echo in
here.
I don't think it works that way.
On 3/12/02 1:56 PM, "McGrath, Jim" <[EMAIL PROTECTED]> wrote:
> This message is from the T13 list server.
>
>
>
> I doubt the function will be provided above 137 GB by vendors, since the
> host requirements today are dominated by the need to run old code, which
> won't run above 137 GB anyway.
>
> Jim
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 12, 2002 12:26 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [t13] but already we did drop Read/Write Long
>
>
> This message is from the T13 list server.
>
>
> Instead of defining "proprietary vendor-specific extension" to deliver
this
> function by each manufacturer for above 128GB drives, will it make more
> sense for T13 to "unify" this efforts?
>
> Raymond Liu
>
> -----Original Message-----
> From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 12, 2002 11:53 AM
> To: [EMAIL PROTECTED]
> Subject: [t13] but already we did drop Read/Write Long
>
>
> This message is from the T13 list server.
>
>
> [ BC [EMAIL PROTECTED] ]
>
>> Harlan Andrews 03/12/02 10:15AM
>> Although Read/Write long
>> may have been deleted from the spec,
>> it is STILL a requirement
>> for several Host vendors. Drive suppliers
>> should be very careful not to actually remove
>> the Read/Write long commands.
>
> But we Ansi T13 the committee actually have flatly removed Read/Write
Long
> above 128GiB @ 0.5KiB/block (and Ansi T10 has removed them above 2TiB)
...
>
> ... no?
>
> Up above 128GiB, there's nothing an Ata drive vendor can do to bring
these
> back, except provide some reasonable proprietary vendor-specific
extension
> to deliver the same function. Ditto for Scsi/Atapi work up above 2TiB.
>
> The legit uses for these ops known to me are to make a Read respond
slowly
> without an error and to make a Read report an error. This is how I most
> easily observe, for example, that some drives have an entirely creative
idea
> of what the correct Pio protocol is for reporting a read error.
>
> I can imagine being limited to below 128GiB to perform error injection
like
> this won't much matter ... I guess soon enough we'll all find out.
>
> Slow writes and Write errors have always been harder to observe. Scsi
> ModeSelect sometimes will give you some reasonably repeatable Write
errors,
> but I've never had a good way to get individual Write's to be slow.
>
>> Thomas Colligan 03/12/02 12:06PM
>> Gee! yet another use for the W/R long commands.
>
> Nothing like removing a feature to dig out how it actually is helping
> people.
>
> Pat LaVarre
>
>> RE: [t13] Read/Write Long
>>>> [EMAIL PROTECTED] 03/12/02 11:42AM >>>
> This message is from the T13 list server.
>
>
> In the ATA RAID1 (disk mirroring) application, R/W Long has been used to
> perform forced error on the rebuild drive in certain LBA (when the host
> cannot get valid data from the corresponding LBA in source drive during
the
> mirror rebuild process). This will force the OS to recognize the error
> situation when OS is trying to access the data from that LBA. Without
R/W
> Long, it will require a much more complicated error handling algorithm to
> handle the situation.
>
> Raymond Liu
