On 08/02/2012 02:27 PM, Christoph Hellwig wrote:
On Thu, Aug 02, 2012 at 02:25:56PM +0800, Asias He wrote:
We need to support both REQ_FLUSH and REQ_FUA for bio based path since
it does not get the sequencing of REQ_FUA into REQ_FLUSH that request
based drivers can request.
REQ_FLUSH is emulated by:
1. Send VIRTIO_BLK_T_FLUSH to device
2. Wait until the flush is finished
There is no need to wait for the flush to finish if the REQ_FLUSH
request has no data payload.
Even if it has a payload waiting is highly suboptimal and it should
use a non-blocking sequencing like it is done in the request layer.
So, for REQ_FLUSH, what we need is that send out the VIRTIO_BLK_T_FLUSH
and not to wait.
REQ_FUA is emulated by:
1. Send the actual write
2. Wait until the actual write is finished
3. Send VIRTIO_BLK_T_FLUSH to device
4. Wait until the flush is finished
5. Signal the end of the write to upper layer
The same comment about not blocking applies here as well.
We still need to wait until the actual write is finished here?
Like,
REQ_FUA is emulated by:
1. Send the actual write
2. Wait until the actual write is finished
3. Send VIRTIO_BLK_T_FLUSH to device
4. Signal the end of the write to upper layer
--
Asias
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
