This message is from the T13 list server.
That's interesting Hale, because as a host vendor that's NOT what I expect to have happen. If the reality is that some very large % of the drives implement it this way, then I'd have no problem changing it. But, if it's the other way around then I'd have a problem changing it because it doesn't reflect reality. The other way out of this going forward is to have a seperate bit indicating if the read cache is completely disabled by this set features or not. ::>-----Original Message----- ::>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On ::>Behalf Of Hale Landis ::>Sent: Tuesday, June 28, 2005 10:36 PM ::>To: [email protected] ::>Subject: RE: [t13] Read Look Ahead ::> ::>This message is from the T13 list server. ::> ::> ::>On Tue, 28 Jun 2005 22:15:51 -0700, Mark Overby wrote: ::>>This message is from the T13 list server. ::>>I'm not sure we have consensus on this and I'm not sure that was the ::>>original intent of that bit. ::> ::>Actually we are talking about the name of the SET FEATURES ::>subcommands that has generally been called Enable/Disable Read ::>Ahead. Probably for the last 10 years the function actually performed ::>is to enable/disable Read Cache. ::> ::>>It would appear (based on the discussions at the plenary and side ::>>discussions I've had with people) that some drives ::>implement this as a ::>>read cache enable/disable others implement it differently. ::> ::>I would agree there are many different implementations of Read (and ::>Write Cache) but I think most people expect the SET FEATURE ::>subcommands in question to enable/disable the Read (or Write) cache ::>feature/function in the drive no matter what the actual cache ::>implementation is. ::> ::>Hale ::> ::> ::>*** Hale Landis *** www.ata-atapi.com *** ::> ::> ::> ::>
