This message is from the T13 list server.
Andre, I get the feeling your using drugs (again?)! Give me a scenario that you perceive will fail using FUA on queued or non-queued commands, then we can have a useful discussion. Just blowing smoke, as you've done below, does nothing to resolve the issue. Please keep in mind the issues that the FUA proposal is trying to resolve: 1. Flush doesn't flush on all drives, 2. Flush significantly kills performance, which is why many drives ignore the command and many drivers don't send the command. MS wants a quick way to get critical data on the media at the time of the command so they have somewhat of a guarantee that the critical data is put to bed without killing performance, which is a great idea. So give me a scenario... Keep smiling! MKE ;-) -----Original Message----- From: Andre Hedrick [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 10:50 PM To: Steve Livaccari Cc: Curtis Stevens; T13 List Server; [EMAIL PROTECTED] Subject: Re: [t13] hmmm.. no comments? 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 *** > > > > > > > > > > > > > > > >
