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

[Gary Laatsch]

Title: ATA-7 Write DMA Queued FUA EXT problem

As I think about this more some of the discussion is coming back.  I do remember discussing similar to what Mark is talking about now.  I dont remember exact details, but I remember discussing how drives use automation and things like read from write cache, etc.  I do specifically remember Nita saying in their (MS) application they wouldn't be requesting FUA on recently written data (as in Mark's example), that it would always be some other area of the disk (log files).  However, we discussed that if the function was avaialble, we would have to consider the fact that someone might attempt to do a FUA over a requested read area or a write area that maybe hadn't been flushed yet.   I also noticed in the minutes from June 2002 meeting (e02124r0) there was some comments regarding SATAII and a similar function being done differently?????  Not being involved in SATA, I am not sure what that is about.   Gary Laatsch [EMAIL PROTECTED] ----- Original Message ----- From: Gary Laatsch To: Mark Vallis ; [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 6:37 PM Subject: Re: [t13] 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