Re: [t13] FUA operations

[Harlan E. Andrews]

This message is from the T13 list server.

Tony,

It seems wrong to me.  Can someone explain the rational for that 
behavior.

I don't think current devices actually work that way.   Surely we don't 
want that behavior, do we ?

Regards,

Harlan

On Wednesday, July 9, 2003, at 12:11PM, Tony Goodfellow wrote:

This message is from the T13 list server.

Nathan: The following explanes the situation:

Section 6.9 in ATA-6 defines the commands in the "Overlapped Feature 
Set",
section 4.19 in ATA-7 - Flush Cache is not in the list.

Section 6.10 in ATA-6 (4.20 in ATA-7) defines the Queued. It states: 
"If a
queue exists when a non-queued command is received, the non-queued 
command
shall be command aborted and the commands in the queue shall be 
discarded."

Tony Goodfellow

-----Original Message-----
From: Nathan Obr [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 8:59 AM
To: Tony Goodfellow
Cc: [EMAIL PROTECTED]
Subject: RE: [t13] FUA operations
Tony,
        I don't understand why you think a flush cache will result in
queued commands ever being aborted.
	The Flush Cache (ATA6 8.12) description states:
--------
	This command is used by the host to request the device to flush
the write cache. If there is data in the write cache, that data shall 
be
written to the media. The BSY bit shall remain set to one until all 
data
has been successfully written or an error occurs.
--------

        It doesn't say anything about queues or aborting them.  Am I
looking in the wrong spot?
Nathan

-----Original Message-----
From: Tony Goodfellow [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 8:37 AM
To: Nathan Obr; Harlan Andrews; Hugh Curley
Cc: [EMAIL PROTECTED]
Subject: RE: [t13] FUA operations
Nathan's last comment "just send down a flush cache command" is only
valid
if there are no released command in the drive. A Flush Cache command
will
result in any queued commands being aborted - i.e. the queue is cleared
before completion.
-----Original Message-----
From: Nathan Obr [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 4:52 PM
To: Harlan Andrews; Hugh Curley
Cc: [EMAIL PROTECTED]
Subject: RE: [t13] FUA operations
This message is from the T13 list server.

Harlan,

        FUA doesn't have any relevance to a queue.
        FUA can return before other requests which were ahead of the
queue have been flushed to the media. Only the FUA command/data itself
has to be on the media before it can return.
        If we wanted to write a command and all the others before it to
disk, we would just send down a flush cache command.
Nathan

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Harlan Andrews
Sent: Monday, June 30, 2003 4:09 PM
To: Hugh Curley
Cc: [EMAIL PROTECTED]
Subject: Re: [t13] FUA operations
This message is from the T13 list server.

Hugh,

There seems to be some confusion about how FUA works.

Some people seem to think that FUA requests get promoted in the queue.

Others (myself included) believe that FUA should simply delay return
until that request AND ALL other requests ahead of it in the queue have
been flushed to the media.
I believe the drive MUST maintain data integrity even if the write
commands do overlap in the queue.
...Harlan

On Monday, June 23, 2003, at 4:02 PM, Hugh Curley wrote:

This message is from the T13 list server.

Someone requested the FUA command for a specific purpose.  That
purpose is
to immediately execute the write without the performance hit of a
flush
cache.  That is the way the command should work.  Any driver writer
that
issues the FUA command with overlapping reads already in the queue
deserves
what will happen.
The command was requested for an operation that will not include
overlap
data.
I believe it should be included as requested.

If you are really worried about someone messing up the data on the
drive,
should we not eliminate all write commands?
Hugh

----- Original Message -----
From: "Gary Laatsch" <[EMAIL PROTECTED]>
To: "Curtis Stevens" <[EMAIL PROTECTED]>; "T13 List Server"
<[EMAIL PROTECTED]>
Sent: Monday, June 23, 2003 3:40 PM
Subject: Re: [t13] hmmm.. no comments?

This message is from the T13 list server.

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 ***













This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they 
are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.