On 05/16/2012 12:04 PM, Christoph Hellwig wrote: > On Wed, May 16, 2012 at 12:05:51PM +0900, MORITA Kazutaka wrote: >>> > > flushing the cache, we already have mechanism to to do this, qemu-io -c >>> > > "flush". >> > >> > IMHO, the uppler layer should assume that the underlying one provides >> > a block storage semantic to simplify the implementation. And >> > actually, there is no other block driver in QEMU and OpenStack which >> > needs a flush request to read the latest data from another node. > Actually there is in QEMU - it's file backed images on NFS for certain > coner cases, and they are a massive PITA to handle, last time I checked > with Redhat-private patches not even in upstream qemu for live > migration. > Even there isn't any block driver in QEMU issuing flush before reading for any corner case. I will insist on fixing the problem in the upper layer because (quote from 'Worse is Better'): "Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. " So my point is, interface to upper layer should adopt to the lower level implementation, *if* we have a rationale behind. In our case, restriction in upper layer(be it adding a flush before reading, use correct cache mode for snapshot.etc.) will benefit us 1) the problem we have for now will disappear completely 2) greatly reduce the internal implementation logic But anyway, if it is not easy to fix upper layer or want to get most backward compatible, it would be better to try our best effort (with minimal cost) to handle(reduce) the problem in the lower implementation. Thanks, Yuan |