This message is from the T13 list server.
Nathan, Sweet! This is what I like to hear. Andre Hedrick LAD Storage Consulting Group On Sun, 29 Jun 2003, Nathan Obr wrote: > Andre, > Microsoft did not deem it all important to jump the queue. FUA > does not jump the queue. FUA doesn't have anything to do with queues. > Discussing write ordering with respect to FUA makes no sense as the two > have nothing to do with each other. > I have never spoken to you about FUA nor has it come up while we > were together at T13, so I assume the amendment to FUA you made came > while Nita was our representative, so I don't have any details on why > the amendment was rejected. > However, I do know what reflector I am mailing. T13 is a > committee, where Microsoft has only 1 vote and holds no office. If you > would like to change ATA-7, make a proposal and we will discuss it on an > all technical level. > > Nathan > > -----Original Message----- > From: Andre Hedrick [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 28, 2003 4:53 PM > To: Nathan Obr > Cc: T13 List Server > Subject: RE: [t13] hmmm.. no comments? > > > Nathan: > > Not to be rude, but what reflector are you mailing. > I made a friendly proposal/ammendment to FUA to enable forced write > ordered events. It got rejected, period. The reason was MicroSoft > deemed > it all important to jump the queue. > > Now to clear the point. Add to FUA the option to force ordering where > as > sane and proper filesystems can trust their host driver will be in > control > of FUA operations. I do not care how or why MicroSoft needs or wants > this > feature; however, to rudely refuse ammendments to assist the acceptance > will yeild toasty discussions. > > Grant the addition of one bit in the features register when FUA is > enabled > to allow and forced ordered behavior. You are quoting T10, but the > behavior the device is not that of T10. So if FUA is going to have a > chance and not earn the label of "DATA CORRUPTION FEATURE", introduced > by > MicroSoft, consider adjusting the stance and work with the concerns of > your peers. > > 800 pound gorillas face mortality when the elephant gun arrives. > > Nothing personal, all technical. > > Cheers, > > > Andre Hedrick > LAD Storage Consulting Group > > On Thu, 26 Jun 2003, Nathan Obr wrote: > > > This message is from the T13 list server. > > > > > > I am sending this as a test. I haven't been able to get onto the T13 > > List Server yet although I have been trying to reply to this thread > for > > a while. I apologize if I reawaken the issue. For those who were not > > at the T13 meeting this week, the original issue has been resolved and > > hopefully the below clarification will resolve any outstanding ones. > > ------------------------ > > > > [My original, long delayed email] > > Everyone has made far too big of a deal out of this. First off, FUA > > doesn't affect queuing or write ordering. The only difference between > > FUA I/O and other types of I/O is that FUA has the added restriction > > that the data must be to the medium before the drive can say the > > transaction is complete. That's it. The drive may still queue the > > command and handle it however it sees fit. It seems like there should > > be more to it, but there isn't. > > > > Hopefully, you can see that there is no need for concern over > overlapped > > LBA or affects on the queue as it doesn't affect write ordering or the > > queue. > > > > By the way, before too many people decide to jump ship for T10, you > will > > be interested to know that SCSI has had support for FUA for quite some > > time (See SBC). Many hard drive manufacturers shouldn't have a > problem > > implementing this as much of it can be borrowed from their existing > SCSI > > lines. > > > > Nathan > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Curtis Stevens > > Sent: Monday, June 23, 2003 7:39 PM > > To: T13 List Server > > Subject: Re: [t13] hmmm.. no comments? > > > > This message is from the T13 list server. > > > > > > Gary > > > > The wording you propose would defeat the purpose of the command. > I > > do > > not know if you were there for the discussion. The purpose of the FUA > > was > > to cause critical data to be committed to the media, regardless of > what > > is > > in the que. If you wait for a flush you are delaying the higher > > priority > > data. Furthermore, If you know that the area you are writing is for > > this > > type of critical data you can prevent the issue you are trying to > solve > > in > > the drive... Queued FUA is not a function for everyday use, but if > you > > use > > it for the purpose intended it has great value. Fir instance, if > power > > has > > been removed from the system and you only have a few MS to store the > > state, > > you would wrather not wait for the que to execute or flush, nor would > > you > > want to go through the very time consuming process of aborting the > que. > > You > > simply was the state information committed in the shortest possible > > time. I > > see this as one of the main uses for queued FUA commands. > > > > --------------------------- > > Curtis E. Stevens > > 29 Dewey > > Irvine, Ca 92620 > > > > Home: (949) 552-4777 > > E-Mail: [EMAIL PROTECTED] > > > > The face of a child can say it all, especially the mouth part of the > > face... > > ----- Original Message ----- > > From: "Gary Laatsch" <[EMAIL PROTECTED]> > > To: "Curtis Stevens" <[EMAIL PROTECTED]>; "T13 List Server" > > <[EMAIL PROTECTED]> > > Sent: Monday, June 23, 2003 2:40 PM > > Subject: Re: [t13] hmmm.. no comments? > > > > > > > Curtis, > > > > > > Dropping HDD's is one of those very unsafe thing to do :-) > > > > > > My 2 cents on the whole deal is simple. Mark Vallis brought up a > very > > good > > > point in his example of 2 read requests and the 1 write request in > the > > queue > > > and than overlapped by a FUA Write request. The current ATAPI-7 > spec > > > indicates that the FUA command shall not be released. Obviously if > > you do > > > this, the result is the read data returned is in question (return > the > > old > > or > > > new data, the command was recieved before but processed after). > Also, > > the > > > queued write would request data that should be older then the data > > just > > > written with the FUA since the command was actually recieved before. > > I > > > think this is really an exception case and should be handled as > such. > > > > > > My opinion is to modify the wording to the queued FUA commands to > add > > > something like "if the queued FUA request overlaps a previously > queued > > > command, that the queue shall be flushed....blah blah blah" or > however > > we > > > say it in T13 queue-ish. The biggest issue is that in this case, > the > > FUA > > > needs to release and it slows down because of the clean up needed to > > insure > > > data integrity. But I know that you guys will figure it out this > week > > up > > > there in SJ. Have fun. > > > > > > Gary Laatsch > > > [EMAIL PROTECTED] > > > > > > ----- Original Message ----- > > > From: "Curtis Stevens" <[EMAIL PROTECTED]> > > > To: "T13 List Server" <[EMAIL PROTECTED]> > > > Sent: Monday, June 23, 2003 10:20 AM > > > Subject: Re: [t13] hmmm.. no comments? > > > > > > > > > > This message is from the T13 list server. > > > > > > > > > > > > I really don't think the issue is one of implementation... It > looks > > to > > me > > > > like there are some concerns about usage and the possibility of > > unexpected > > > > outcomes. MS clearly stated that they understood several of the > > > unexpected > > > > outcomes and still needed the capability. There are many "unsafe" > > things > > > > you can do to an HDD, but that has not prevented commands from > being > > > > implemented. > > > > > > > > --------------------------- > > > > Curtis E. Stevens > > > > 29 Dewey > > > > Irvine, Ca 92620 > > > > > > > > Home: (949) 552-4777 > > > > E-Mail: [EMAIL PROTECTED] > > > > > > > > The face of a child can say it all, especially the mouth part of > the > > > face... > > > > ----- Original Message ----- > > > > From: "Eschmann, Michael K" <[EMAIL PROTECTED]> > > > > To: "T13 List Server" <[EMAIL PROTECTED]> > > > > Sent: Monday, June 23, 2003 8:23 AM > > > > Subject: RE: [t13] hmmm.. no comments? > > > > > > > > > > > > > This message is from the T13 list server. > > > > > > > > > > > > > > > My (humble?) opinion is that FUA is necessary and is not > dangerous > > as > > > long > > > > as a disk drive properly deals with outstanding requests. > > > > > > > > > > First off a flush is very slow, affecting system benchmark > scores > > by > > as > > > > much as 5%. The more interesting fact is that not all drives > > properly > > > > support flush, where many HDD's will complete the Flush command > > without > > > > writing any cached data to media just because of the desire to > make > > ones > > > > disk synthetically faster than somebody elses. > > > > > > > > > > FUA allows the OS to flush critical data without adversely > > affecting > > > > performance. The drive should be required to test all outstanding > > writes > > > > (in the queued case) and assure that the writes are ordered to > > guarantee > > > no > > > > data loss. Lets take a look at a specific scenario: > > > > > > > > > > - Queued write 256 sectors to LBA 10000 > > > > > - FUA write 1 sector 10001 > > > > > > > > > > The 256-sector write must be written to media, or the 1 sector > > must > > > > over-write the same sector written by the 256 sector write in the > > devices > > > > cache. The drive must also assure that the media results in the > > same > > > data. > > > > I'm sure we could expand this simple case to something much more > > complex, > > > > but the basic idea remains: The drive must handle ordering such > > that > > > there > > > > is no data loss. I've asked once before, and I'll ask it again: > > someone > > > > offer up a more complex scenario where you believe FUA will break > > and we > > > can > > > > then have a real conversation about the (de)merits of FUA. > > > > > > > > > > MKE. > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Harlan Andrews [mailto:[EMAIL PROTECTED] > > > > > Sent: Friday, June 20, 2003 4:47 PM > > > > > To: Andre Hedrick; Steve Livaccari > > > > > Cc: Curtis Stevens; T13 List Server; [EMAIL PROTECTED]; Larry > > Barras > > > > > Subject: Re: [t13] hmmm.. no comments? > > > > > > > > > > > > > > > This message is from the T13 list server. > > > > > > > > > > > > > > > I have not been present at any of the discussions, but > > Out-Of-Order > > > > > writes are inherently dangerous to ANY file system - not only to > > > > > journaling. Now that we have Flush Cache as a mandatory > command, > > why > > > > > don't we simply issue the Flush Cache to force unit access. > > > > > > > > > > I have not heard any real benefit for such a dangerous > operation. > > Why > > > > > would anyone even consider it ? > > > > > > > > > > ...Harlan > > > > > > > > > > on 6/19/03 10:49 PM, [EMAIL PROTECTED] wrote: > > > > > > > > > > >This message is from the T13 list server. > > > > > > > > > > > > > > > > > > > > > > > >Steve, > > > > > > > > > > > >This totally nukes and destroys write ordered operations. > > > > > >Example is the down/commit block on a journalled operation. > > > > > > > > > > > >Taking an FUA command to platter and blasting past the queue > > cache > > will > > > > > >destroy every bit of the security designed into any journaling > > file > > > > > >system. > > > > > > > > > > > >I still do not get why MicroSoft thinks there journaling NTFS > of > > the > > > > > >meta data in OS buffer cache will not take a hit. If I knew > the > > OS > > my > > > > > >data was dependent on did such a "FOOLISH" operation I would > find > > > > another. > > > > > > > > > > > >If T13 continues to move towards making it possible for the > HOST > > to > > do > > > > bad > > > > > >things, then the DEVICE is even worse. > > > > > > > > > > > >We can all pack our bags and go home and switch to T10, because > > nobody > > > > > >will trust a device coming out of T13 again. > > > > > > > > > > > >Comments? > > > > > > > > > > > >Tomato Shield UP!! > > > > > > > > > > > >Andre Hedrick > > > > > >LAD Storage Consulting Group > > > > > > > > > > > >On Wed, 18 Jun 2003, Steve Livaccari wrote: > > > > > > > > > > > >> This message is from the T13 list server. > > > > > >> > > > > > >> > > > > > >> > > > > > >> All modern HDD's have a buffer for write cache that is used > to > > stack > > > up > > > > > >> write data from both queued and unqueued write commands. A > > write > > > > command > > > > > >> followed by a flush cache command will likely not move the > data > > from > > > > the > > > > > >> last write command to the media until the rest of the data is > > the > > > write > > > > > >> cache is written. If a write FUA command is used the data > from > > the > > > > write > > > > > >> FUA command will be given priority over the other data in the > > write > > > > cache > > > > > >> and be written first. > > > > > >> > > > > > >> > > > > > >> > > > > > >> Regards, > > > > > >> Steve Livaccari > > > > > >> > > > > > >> Hard Drive Engineering > > > > > >> IBM Global Procurement > > > > > >> Internet: [EMAIL PROTECTED] > > > > > >> Phone (919) 543.7393 > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > >> "Curtis Stevens" > > > > > > > > > > > > > > > > >> <[EMAIL PROTECTED] To: "T13 > > List > > > > Server" > > > > > ><[EMAIL PROTECTED]> > > > > > >> oo.com> cc: > > > > > > > > > > > > > > > > >> Sent by: Subject: Re: > > [t13] > > > > hmmm.. > > > > > no > > > > > >comments? > > > > > >> [EMAIL PROTECTED] > > > > > > > > > > > > > > > > >> rg > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> 06/17/2003 11:09 > > > > > > > > > > > > > > > > >> PM > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> This message is from the T13 list server. > > > > > >> > > > > > >> > > > > > >> Gary > > > > > >> > > > > > >> As I recall, there were some inacuracies in the proposals > > as > > made > > > > to > > > > > >> the > > > > > >> committee. There were many revisions. The only new FUA > > commands > > > that > > > > make > > > > > >> sense are the queued ones. All others could be followed by > > flush > > > > cache. > > > > > >> > > > > > >> --------------------------- > > > > > >> Curtis E. Stevens > > > > > >> 29 Dewey > > > > > >> Irvine, Ca 92620 > > > > > >> > > > > > >> Home: (949) 552-4777 > > > > > >> E-Mail: [EMAIL PROTECTED] > > > > > >> > > > > > >> The face of a child can say it all, especially the mouth part > > of > > the > > > > > >> face... > > > > > >> ----- Original Message ----- > > > > > >> From: "Gary Laatsch" <[EMAIL PROTECTED]> > > > > > >> To: "Curtis Stevens" <[EMAIL PROTECTED]>; "T13 List > > Server" > > > > > >> <[EMAIL PROTECTED]> > > > > > >> Sent: Tuesday, June 17, 2003 4:40 PM > > > > > >> Subject: Re: [t13] hmmm.. no comments? > > > > > >> > > > > > >> > > > > > >> > Curtis and Hale, > > > > > >> > > > > > > >> > Also, to expand upon this. I think Hale's point is the > > > proposal > > > > put > > > > > >> > forth by Nita didn't contain the QUEUE FUA or QUEUE FUA EXT > > > commands > > > > and > > > > > >> he > > > > > >> > was wondering where they were added or how they were > > proposed. My > > > > memory > > > > > >> was > > > > > >> > this was discussed and added at the June 2002 meetings. > That > > is > > > why > > > > I > > > > > >> was > > > > > >> > wondering if anyone else remembered these discussions. I > > remember > > > > > >> > discussing all of this stuff (even Andre's comments about > the > > FUA > > > > blowig > > > > > >> > away the queue) but for some reason it just wasn't captured > > very > > > well > > > > in > > > > > >> the > > > > > >> > minutes. > > > > > >> > > > > > > >> > Gary Laatsch > > > > > >> > [EMAIL PROTECTED] > > > > > >> > > > > > > >> > ----- Original Message ----- > > > > > >> > From: "Curtis Stevens" <[EMAIL PROTECTED]> > > > > > >> > To: "T13 List Server" <[EMAIL PROTECTED]> > > > > > >> > Sent: Tuesday, June 17, 2003 3:15 PM > > > > > >> > Subject: Re: [t13] hmmm.. no comments? > > > > > >> > > > > > > >> > > > > > > >> > > This message is from the T13 list server. > > > > > >> > > > > > > > >> > > > > > > > >> > > Hale > > > > > >> > > > > > > > >> > > I was there during the discussions and there was no > > secret > > > > > >> committee. > > > > > >> > > Basically, MS stated that they wanted to force meta data > to > > the > > > > drive > > > > > >> > > without blowing the que. This means that although it is > > possible > > > > to > > > > > >> lose > > > > > >> > > data, in their application data loss would not occur... > > > > > >> > > > > > > > >> > > --------------------------- > > > > > >> > > Curtis E. Stevens > > > > > >> > > 29 Dewey > > > > > >> > > Irvine, Ca 92620 > > > > > >> > > > > > > > >> > > Home: (949) 552-4777 > > > > > >> > > E-Mail: [EMAIL PROTECTED] > > > > > >> > > > > > > > >> > > The face of a child can say it all, especially the mouth > > part > > of > > > > the > > > > > >> > face... > > > > > >> > > ----- Original Message ----- > > > > > >> > > From: "Hale Landis" <[EMAIL PROTECTED]> > > > > > >> > > To: "T13 List Server" <[EMAIL PROTECTED]> > > > > > >> > > Sent: Tuesday, June 17, 2003 10:57 AM > > > > > >> > > Subject: [t13] hmmm.. no comments? > > > > > >> > > > > > > > >> > > > > > > > >> > > > This message is from the T13 list server. > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > I'm curious why there are no comments about the > question > > of > > the > > > > > >> > > > origin of the WRITE DMA QUEUED FUA command (where is > the > > > > proposal?). > > > > > >> > > > And why no comments on QUEUED EXT commands with large > > sector > > > > counts. > > > > > >> > > > > > > > > >> > > > Is this because all these discussions must take place > via > > the > > > > "secret > > > > > >> > > > society"? > > > > > >> > > > > > > > > >> > > > Hale > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > *** Hale Landis *** www.ata-atapi.com *** > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > >
