On 05/11/2012 02:43 AM, MORITA Kazutaka wrote: > Note that this doesn't still pass the testcase I posted before: > > == > $ qemu-img convert ~/linux.img sheepdog:linux > $ collie vdi read linux 0 512 | hd | head -1 > 00000000 fa eb 7c 6c 62 61 4c 49 4c 4f 01 00 15 04 09 00 |..|lbaLILO......| > $ qemu-img snapshot -c snap sheepdog:linux > $ collie vdi read linux 0 512 | hd | head -1 > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > == > > I guess it is because read_object() doesn't read the cached data. > > This is a wrong behavior as a block storage because we need to read > the latest data even if it is not flushed, so I hope it would be fixed > too. No, read_object() will try to read cache first. In above example, the inode object in the cache is NOT correct due to unsafe mode converting. So behavior of object cache looks right even to this case. I spent some time on this problem, the real problem is 'qemu-img convert' use UNSAFE mode as default, which doesn't flush at all (for writeback mode, qemu-img will issue a flush at the close(), but for unsafe, no flush at all). 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? Thanks, Yuan |