Curtis,
When you say "state" information, I assume you are referring to information which is vital to prevent damage to system structures due to a power failure. You are correct in that there is very little warning of a power failure. In fact, I think there is usually NO guaranteed warning for a power failure.
The trick is to make the state of the disk consistent at all times. This is usually done by guaranteeing that directory changes are ALWAYS valid. To do this, the new structure is constructed as an unlinked copy of the old structure. Then the changes are made to the copy. When the copy is consistent, the LAST step is to link it in to the actual directory in a SINGLE write of a single sector. Not coincidentally, some data bases use a similar technique.
Typically, you would WANT a flush cache before the final link write to guarantee that all previous modifications were actually on the media before linking the new structure.
Are you saying that you can completely clean up the directory structures after receiving a power fail warning ?
The flush cache was designed EXACTLY for that use, but even before that command existed the OS folks used other methods to insure that the drive's cache was completely written to the media prior to the link write ( or prior to a planned power off ).
I think the FUA has serious potential for misuse. If extra complexity is introduced to the hard drives, it could ALSO cause the drives to mishandle normal read/writes.
5% savings on a BENCHMARK is a poor excuse to introduce potential data corruption. The current benchmarks have little relation to real system performance. A 5% savings in benchmark will NOT result in a 5% improvement to system performance using real applications.
However, improperly re-ordering the queue could completely destroy data integrity.
Regards,
Harlan
On Monday, Jun 23, 2003, at 19:38 US/Pacific, Curtis Stevens wrote:
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,good
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 verypoint in his example of 2 read requests and the 1 write request in thequeueand than overlapped by a FUA Write request. The current ATAPI-7 specor
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 oldnew data, the command was recieved before but processed after). Also, theinsure
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 todata integrity. But I know that you guys will figure it out this week upme
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 tounexpectedlike there are some concerns about usage and the possibility ofthingsoutcomes. MS clearly stated that they understood several of theunexpectedoutcomes and still needed the capability. There are many "unsafe"asface...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 thelong----- 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 asas a disk drive properly deals with outstanding requests.
First off a flush is very slow, affecting system benchmark scores bywritesmuch 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.performance. The drive should be required to test all outstanding
FUA allows the OS to flush critical data without adversely affectingdevices(in the queued case) and assure that the writes are ordered to guaranteenodata loss. Lets take a look at a specific scenario:over-write the same sector written by the 256 sector write in the
- 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 mustcomplex,cache. The drive must also assure that the media results in the samedata.I'm sure we could expand this simple case to something much moresomeonebut the basic idea remains: The drive must handle ordering such thatthereis no data loss. I've asked once before, and I'll ask it again:willoffer up a more complex scenario where you believe FUA will break and wecanthen 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 cachemydestroy 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 OSdoanother.data was dependent on did such a "FOOLISH" operation I would find
If T13 continues to move towards making it possible for the HOST tonobodybadthings, then the DEVICE is even worse.
We can all pack our bags and go home and switch to T10, becausestackwill 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 toupfromcommandwrite data from both queued and unqueued write commands. A writefollowed by a flush cache command will likely not move the datamadethewritelast write command to the media until the rest of the data is thewritecache is written. If a write FUA command is used the data from thecacheFUA command will be given priority over the other data in the writeServer"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 Listhmmm..<[EMAIL PROTECTED]>oo.com> cc:
Sent by: Subject: Re: [t13]nocomments?[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 asthetothatthe committee. There were many revisions. The only new FUA commandsmakecache.sense are the queued ones. All others could be followed by flush
--------------------------- 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 ofrememberproposalface... ----- 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 theputcommandsforth by Nita didn't contain the QUEUE FUA or QUEUE FUA EXTandwhymemoryhewas wondering where they were added or how they were proposed. Mywasthis was discussed and added at the June 2002 meetings. That isIwaswondering if anyone else remembered these discussions. Ipossiblewellblowigdiscussing all of this stuff (even Andre's comments about the FUAaway the queue) but for some reason it just wasn't captured veryindrivetheminutes.committee.
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 secretBasically, MS stated that they wanted to force meta data to thewithout blowing the que. This means that although it isoftolosedata, 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 partthetheface...----- 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 ofproposal?).origin of the WRITE DMA QUEUED FUA command (where is thecounts.And why no comments on QUEUED EXT commands with large sector"secret
Is this because all these discussions must take place via thesociety"?
Hale
*** Hale Landis *** www.ata-atapi.com ***
