[Sheepdog] [PATCH v6 7/8] collie: read the cached objects if any for collie operation
Liu Yuan
namei.unix at gmail.com
Thu Apr 5 09:28:10 CEST 2012
On 03/31/2012 06:23 PM, Liu Yuan wrote:
> On 03/31/2012 05:29 PM, MORITA Kazutaka wrote:
>
>> At Sat, 31 Mar 2012 15:34:10 +0800,
>> Liu Yuan wrote:
>>>
>>> On 03/31/2012 03:20 PM, MORITA Kazutaka wrote:
>>>
>>>> - Read requests:
>>>> read from a object cache always when the cache exists
>>>>
>>>> - Write requests:
>>>> flush and remove a object cache if SD_FLAG_CMD_CACHE is not set
>>>>
>>>> Isn't this okay for collie, too?
>>>
>>>
>>> Who set SD_FLAG_CMD_CACHE for collie? user or let collie decide itself?
>>
>> We don't need to set the same cache flag to the collie requests.
>>
>> Collie doesn't send write requests to the opened VDIs, so collie
>> doesn't flush the existing caches with my idea.
>>
I think this assumption is broken, collie vdi snapshot will do WRITE the
other's opened VDI....
So collie vdi snapshot will simply remove the object cache of the victim
Guest... this is quite costy operation.
So I'd like insisting that, we'd better not try to fix the bug that
should be fixed elsewhere. I think qemu-img convert should use
cache=passthrough mode, it is unfriendly for it to use writeback cache.
Thanks,
Yuan
>>>
>>> For Guests, SD_FLAG_CMD_CACHE is set once we start up QEMU with object
>>> cache enabled. So we'd need to distinguish R&W requests. If we see
>>> SD_FLAG_CMD_CACHE, sheep can simply flush and delete the cache. So this
>>> looks extraneous for Guest request handling.
>>
>> All requests (including collie's ones) must follow the following
>> rules:
>>
>> - If the target object is writable, only one client can send requests
>> against it. If other ones read data from the writable object, the
>> read data may not be the latest.
>>
>> - If the target object is read-only, no client can send write
>> requests against it, but any clients can send read ones.
>>
>> If sheep receives a non-cache write request, it means no other clients
>> don't open the VDI with a writeback mode, so we can flush and remove
>> the object cache safely. And, even if sheep receives a non-cache read
>> request, other clients may open the VDI with a writeback mode, so it
>> is not good to flush the cache in the such case. This is the key idea
>> behind my suggestion.
>>
>> However, if you think it is not good to distinguish read and write requests
>> for cache handling, I don't mind to drop my idea.
>>
>
>
> Actually, I don't understand your idea. I didn't notice that collie
> doesn't issue write requests. If we can resolve the problem, I am not
> against your idea.
>
> Thanks,
> Yuan
More information about the sheepdog
mailing list