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
