This message is from the T13 list server.
Pat, Once again, this has nothing to do with PIO or UDMA. Storage devices have ALWAYS had the ability to begin media modifications "before all of the data for the command" was received. Indeed, devices try to overlap as much as possible the transfer of data across the interface and its transfer to/from the media in order to maximize performance. I'm a bit surprised that anyone would be surprised by this. Disk drives have operated in this manner for the past 40 years. A lot of software has been created precisely so the the resulting issues can be overcome in some high fault tolerance environment (all of which involve NOT updating in place. Obviously PCs traditionally don't do a lot of that (although it is one reason why some data structures, like FAT tables, are duplicated). Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, December 17, 2001 12:25 PM To: [EMAIL PROTECTED] Subject: RE: [t13] significant byte counts other than the total This message is from the T13 list server. We now have two different Harlan A quotes: the 12/13 original, and the 12/17 restatement. I'm ok with the restatement. In the original, I was choking over the idea that a device, same as a host, should be required to keep all the data of a command buffered until the result of the command crosses the bus. I agree buffering all the data is a reasonable requirement to place on desktop hosts ... though I can imagine embedded host folks complaining. > ... If we now agree devices often do move some data in/out before deciding if the total that will move matches the max that the device's interpretation of the command block permits, ... ... perhaps we can agree that with UDma we will see more data move than we did with Pio? Pat LaVarre >>> Harlan Andrews <[EMAIL PROTECTED]> 12/17/01 01:11PM >>> Pat, This was meant EXACTLY as quoted. NO data is valid until the transfer is completed and the data is checked checked. Intermediate data should not be used. In case of error, the ENTIRE transfer should be retried. On read, if the host can't handle ALL the data, it should not request that much. A host should never request more data than it's buffer can receive. If an error happens during write, it is the host's resposibility to retry THE ENTIRE TRANSFER. ...Harlan On 12/17/01, Pat LaVarre <[EMAIL PROTECTED]> said: >This message is from the T13 list server. > > >> Harlan Andrews <[EMAIL PROTECTED]> 12/13/01 05:31PM >> ... >> Neither the device nor the host should use >> ANY intermediate data >> until the transfer is COMPLETED >> and errors are checked. >> Therefore, the "extra" bytes should be completely transparent. > >Hang on a minute, this can't be meant as quoted out of context here? > >An x0A/2A/AA Write block command that fails renders all the content >of the blocks it addresses indeterminate? Maybe commonly only the >blocks before the bad block changed, but only a BadHost assumes >that limited effect? > >Ditto a ModeSelect command: a bad page in the stream doesn't guarantee >that good pages in the stream will have no effect? > >Ditto a WriteBuffer command: a bad Crc for the last burst of bytes doesn't >guarantee the good bytes sent earlier will have no effect? > >Ditto .... > >> Neither the device nor the host should use >> ANY intermediate data >> until the transfer is COMPLETED >> and errors are checked. > >A device can avoid using intermediate data only by buffering all the data >of the command. > >For a command block that moves, say, xFFFF blocks i.e. about 32MiB at >0.5KiB/block, ... no device that buffers less than 32MiB can avoid using >intermediate data. > >Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
