On 01/08/2013 07:19 PM, Kevin Wolf wrote: > I can't see a reason why it would do that. Can you bisect this? >
Sure, bisect it is on my schedule, but I can't promise a deadline. >>>> >>> It seems it is hard to restore into old semantics of cache flags due to >>>> >>> new design of QEMU block layer. So will you accept that adding a >>>> >>> 'flags' >>>> >>> into BlockDriverState which carry the 'cache flags' from user to keep >>>> >>> backward compatibility? >>> >> >>> >> No, going back to the old behaviour would break guest-toggled WCE. >>> >> >> > >> > Guest-toggled WCE only works with IDE and seems that virtio-blk doesn't >> > support it, no? And I think there are huge virtio-blk users. > It works with virtio-blk and SCSI as well. > Okay, I see the code indeed support WCE but it requires Guest kernel to support it. For the kernel doesn't support it, there is no way to disable write cache, no? >> > I didn't meant to break WCE. What I meant is to allow backward >> > compatibility. For e.g, Sheepdog driver can make use of this dedicated >> > cache flags to implement its own cache control and doesn't affect other >> > drivers at all. > How would you do it? With a WCE that changes during runtime the idea of > a flag that is passed to bdrv_open() and stays valid as long as the > BlockDriverState exists doesn't match reality any more. I am not sure if I get it right. What I meant is allow Sheepdog to control cache on the 'cache flags' at startup and ignore WCE on the run time. So you mean, if I choose witeback cache at startup, and then Guest disable it via WCE, then block layer will never send flush request down to Sheepdog driver? Thanks, Yuan