WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH] xen block backend driver.

On Thu, Apr 21, 2011 at 12:03:12PM -0700, Daniel Stodden wrote:
> Yes, everybody is aware that the semantics were broken. But note it's
> not even a consistency issue at this point, because there's currently no
> frontend which relies on the original ordering semantics either. Take
> xen-blkfront, since blk_flush it uses the barrier op for a flush, being
> just a superset when ordering is enforced.

There is a huge userbase of guests out there that does rely on it.

> But before we just enumerate a new command, a potentially more viable
> option would be FLUSH+FUA flags on the WRITE operation. As if mapping
> bio bits.
> 
> The advantage is that it avoids the extra round trip implied by having
> the frontend driving writes through FSEQ_PREFLUSH on their own. I'd
> expect that to make much more of a performance difference. Somewhat
> differentiating PV from the low physical layer.
> 
> Would you, maybe did you, consider that? I think it sounds interesting
> enough to gather performance data, just asking beforehand.

You will need a pure flush anyway.  Once you actually have a correct
implementation you can look into optimizing it.  Note that at least
the Solaris Xen coded added a cache flush to the protocol.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel