This message is from the T13 list server.


On Sun, 29 Jun 2003, Nathan Obr wrote:

> This message is from the T13 list server.
> 
> 
> Hale,
>       The 'right thing' for the disk drive behavior that I was
> referring to is the assumption that after a write to the disk, any read
> from the same address any time after the write, will produce the same
> data.  The presence or absence of a cache should not affect disk
> read/write behavior.  I don't think we need a standard, a spec or a
> white paper for people to understand this.  

If one assumes on a read verify the data come from the platter and not a
spoof for benchmarks.  There was a time in the past two year in Longmont @
The Raintree when a change of behavior was adopted for this reason alone.

>       Drive manufacturer are free to implements something that doesn't
> behave this way, but they will have a hard time getting a logo.  We
> haven't had a hard drive fail for a long time and that is why I say they
> have done the right thing for years.

Okay remove the logo issue, and operate like Bob G and I did in the past.
We did pushed OS issues togather in the spirit of "doing the right thing".

>       FUA is not new to drive manufacturers.  The proposal to add FUA
> to T13 was made a year ago.  The only issue that a hard drive
> manufacturer has had was around releasing which has started this whole
> thread.  That issue was very quickly resolved.  Interestingly, very
> little noise about FUA has come from the hard drive manufacturers,
> however, if you think that FUA as it is in the spec, I suggest you do
> what Western Digital did and write a proposal to change it.

Point taken and noted.  All business, I like it!

Cheers,

Andre Hedrick
LAD Storage Consulting Group

> Nathan
>  
> -----Original Message-----
> From: Hale Landis [mailto:[EMAIL PROTECTED] 
> Sent: Friday, June 27, 2003 8:58 PM
> To: T13 List Server
> Cc: Nathan Obr
> Subject: RE: [t13] Re: hmmm.. no comments?
> 
> On Fri, 27 Jun 2003 13:44:26 -0700, Nathan Obr wrote:
> >I do assume that drive manufacturers will do the right thing, but that
> >is only because they have for years.
> 
> Are you sure? What is the definition of "right thing"? Is it some
> test Microsoft uses for logo certification? Is it just some feeling
> that everyone is doing the "right thing" so there is no problem? I
> don't understand why you seem to have no concerns about this.
> 
> >The only requirement that a host
> >has on a device with a cache is that the cache doesn't change the
> >behavior of the device.
> 
> What behavior? Where is that defined? Is there some standard for how
> a disk drive is supposed to work? Is there a standard for how a disk
> drive cache should work? If such standards exist I've never seen T13
> or ATA/ATAPI-x reference them. Does Microsoft have a document that
> describes in detail how a disk drive works and/or how a disk drive
> cache works? If so, can you share it with us?
> 
> >Any caching scheme that returns data for a
> >sector other than the last data written to that sector has a design
> >mistake,
> 
> Huh? It would not be a "design mistake" if the manufacturer product
> specification defined that their drive did not operate in that
> manner. And I can think of design reasons to implement a drive in a
> manner that you would call a mistake. Sure that may not be a "good
> design" but there is no standard that would say it was
> invalid/illegal. If you or Microsoft think such implementations are
> not possible and/or would never happen then I think you and Microsoft
> need to learn more about how disk drives are operate and how they are
> designed.
> 
> >however, I don't believe any caching algorithm is considered
> >"valid" to ATA/ATAPI as I am not aware that ATA comprehends caching.
> 
> Hmmm... ATA/ATAPI-x define SET FEATURES commands to turn read/write
> caching on/off and then there are the FLUSH CACHE commands. Maybe
> ATA/ATAPI doesn't define how read/write cache should operate but
> ATA/ATAPI does allow the host some control of this drive activity.
> 
> >I believe that device caching behavior is outside of the scope of the
> >ATA protocol and off topic for this forum.
> 
> Perhaps, but again that just reinforces the need for an answer to my
> questions above, especially the question of where is the
> specification or standard or Microsoft document that defines how a
> disk drive and/or a disk drive read/write cache are implemented.
> 
> In another email to the list today you said FUA should not cause
> hardware changes in a drive (I think that is what you said). Before
> you assume FUA is so simple I think you need to talk to some disk
> drive designers.
> 
> Hale
> 
> 
> 
> *** Hale Landis *** www.ata-atapi.com ***
> 
> 
> 

Reply via email to