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

[Eric D. Mudama]

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

Would the driver just send down alternating write/flushregion commands
queued?  If that is the case, the drive will offer 2x the queue depth
(maybe 30% more performance) doing pure WRITE DMA QUEUED FUA (FP)
commands, wouldn't it?  Then again, for a metadata-only journaling
system, this would give you almost 100% of raw performance, with
metadata reliability which means you could always boot the drive.

I'm not sure what percentage of the writes to the filesystem one might
envision doing with this system...

--eric




--
Eric D. Mudama
edmudama@xxxxxxxxxxxxxxxxxxxxx

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