Re: [t13] ATA-7 Write DMA Queued FUA EXT problem

[Gary Laatsch]

Title: ATA-7 Write DMA Queued FUA EXT problem

I am reading back through the minutes and my notes on this.  I remember this was discussed back in June of 2002 (when we voted it into ATAPI-7).  This particular case is not reflected in the minutes (which of course doesnt mean we didnt discuss it).  I tend to agree with Mark.  Nita Pan at MS was the one who was really driving the FUA stuff to insure certain data was written to the disk (eg. bypass write cache).  I don't believe Mark's comments would alter that functionality.  I seem to remember some people not even wanting to add queued FUA saying it defeated the purpose or something to that affect.   anyone else have a better memory or notes than me?   Gary Laatsch [EMAIL PROTECTED] ----- Original Message ----- From: Mark Vallis To: [EMAIL PROTECTED] Cc: Mark Vallis Sent: Sunday, June 15, 2003 11:05 AM Subject: [t13] ATA-7 Write DMA Queued FUA EXT problem T13 Reflector, Western Digital believes there is a problem with the wording under the "description" paragraph for the Write DMA Queued FUA EXT command. The description states "this command shall not be released". There is a fundamental problem if the drive is not allowed to release on this command. Take the following command sequence:       RRR                                         Queued Read #1 - released                 WWW                            Queued Write #1 - released                             RRR                   Queued Read #2 - released WWWWWWWWWWWWWW        Write DMA Queued FUA EXT If the drive released (did not transfer any data) on the first three commands, it's in real trouble if it can't release on the fourth command. It can't provide the host with the proper data for the two released Queued reads. Furthermore, after writing the data for the fourth command to the media, it would have to request Service for the first write, take in the data from the host, and then throw it away. One embodiment of a Queuing implementation would be for the device to release on the fourth command, get the first three commands serviced, then request Service for the fourth command, get the data from the host, and hold BSY until the data is written to the media. The description should reflect the intention of the command which is that the device must write the user data to the media before ending status for the command is reported. Stated another way, WHEN the drive does decide to take the data from the host, it must hold BSY until the data is successfully written on the media. It cannot just take the data into its buffer and then clear BSY. Thank You for your consideration. Mark Vallis