lkml.org 
[lkml]   [2004]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 and later)
Eric D. Mudama wrote:
> On Thu, Jun 10 at 14:02, Jeff Garzik wrote:
>
>> Oh, also:
>>
>> We'll need to write up precisely _why_ this is used, and give some
>> examples of usage, for people reading the proposal (mostly T13-ish
>> people) who have not been following the lkml barrier discussion closely.
>
>
> One comment...
>
> There will need to be queued versions of this command, both legacy
> and first-party, since a flush cache command will abort an outstanding
> queue with error.
>
> Second, I'm trying to figure out exactly how this might be used...


With flush cache range, it should perform exactly the same as a
traditional flush cache with regards to queueing-related issues.

ATA drives normally used without queueing would be a target for this
type of proposal. Hopefully lower-end devices would not have trouble
implementing flush cache (range).

Moving forward, in ATA TCQ is largely a transitory step to NCQ.

As such, Linux will probably have two methods of implementing barriers,
the "pre-NCQ" method, and the NCQ method.

The pre-NCQ method most certainly involves heavy flush cache use.

The NCQ method, I presume, would involve almost exclusive use of queued
FUA commands. That way the OS knows precisely what has not yet hit the
platter, on all data writes to disk. It needs only to wait for queue
completion before submitting the commit block (sector), also FUA.

Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.114 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site