On 05/11/2012 10:59 PM, MORITA Kazutaka wrote: >> I have tried 'qemu-img convert -t writeback' (NOT writethrough), it >> > works well with qemu-img snapshot. >> > >> > So what is the point to use unsafe mode to 'qemu-img convert' for Sheepdog? >> > >> > I'd suggest to patch our README to use 'qemu-img -t writethrough >> > convert'. How about it? > I believe we can solve the above problem without it. > > Note that there still exists a problem; if the cached data is on > another node, it is really difficult to read the latest data. You may > think this is a corner case, but should pay attention as long as we > call Sheepdog a block storage. My suggestion is to document the > restriction (e.g. we shouldn't access the same image from the > different nodes even if it is not the same time) instead of solving > this difficult problem. So seems that even with modification to read_object(), we can't solve this corner case. This restriction is very expensive to afford for upper layer, how it knows where old snapshot is created? Mix creating snapshot with any kind of cache is insane, resulting in lots of code to maintain the consistency, but those code will not be executed at all for most the time(at lest, cautious usage can avoid it completely). That is why I insisted to fix the upper first, and the see what was left to be done to sheepdog. I am wondering if we can patch QEMU's sd_snapshot_create(), asking it never use cache requests at all for snapshot creation(ignore qemu cache mode). Initially, I only used cache for normal IO requests, later review asked to patch all the code patch to use cache flag. Maybe it is time for us to re-visit qemu block layer to see if we really need cache flag for all the code path, including snapshot, migration, etc. Thanks, Yuan |