At Mon, 26 Mar 2012 12:15:29 +0800, Liu Yuan wrote: > > On 03/26/2012 04:41 AM, MORITA Kazutaka wrote: > > > Consider that the object is dirty if the VDI was opened with a > > writeback mode in the previous time. I think we need to check a cache > > here. > > > For the sane usage, VMs should not be opened both for none-cache and > cache mode off and on. Even if VM first open the vdi with cache mode > first, then want to use none-cache mode, current implementation would be > okay, since after the guest was closed, the dirty bits would be flushed > to the cluster. > > So the problem is precisely that we can't handle the situation that VM > runs with cache first, then crashes, then boots up again without cache. > We'd better use qemu-io to issue a flush requests first manually, then > we can safe boot the VM without cache, not losing any dirty data. > > So I don't think it worth introducing complexity to object cache to > handle this corner case that already should be handled by other means.
We can more easily hit this problem. For example: $ qemu-img convert linux.raw sheepdog:linux where linux.raw is a linux image file, and $ qemu sheepdog:linux We cannot boot the linux VDI because qemu-img opens with a BDRV_O_CACHE_WB always, but qemu opens without it by default. I think you are mixing two things in this patchset. 1. use a disk cache (this should be disabled by BDRV_O_NOCACHE) 2. support a writeback mode (this should be enabled by BDRV_O_CACHE_WB) If you think it doesn't make sense to support a writethrough mode with a disk cache, I'm not against to the current approach in this patchset. But at least, please flush a dirty cache before handling non-cache requests. Otherwise, we can easily hit a cache coherency problem (e.g. 'collie vdi list' doesn't show the correct used size). Thanks, Kazutaka -- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
