Re: flush cache range proposal (was Re: ide errors in 7-rc1-mm1 andlater)

[Jeff Garzik]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/