[Sheepdog] [PATCH v6 7/8] collie: read the cached objects if any for collie operation

[Liu Yuan]

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.
> 
>>
>> 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