[Sheepdog] [PATCH] sheep: disable object cache by default

[Liu Yuan]

On 05/10/2012 10:52 AM, MORITA Kazutaka wrote:

> At Thu, 10 May 2012 07:55:46 +0800,
> Liu Yuan wrote:
>>
>> On 05/10/2012 12:20 AM, MORITA Kazutaka wrote:
>>
>>> At Wed, 09 May 2012 21:40:45 +0800,
>>> Liu Yuan wrote:
>>>>
>>>> If you are really concerned of this misbehavior, I think we try re-visit
>>>> Wuyue's patch.
>>>
>>> I guess we'll have to agree to disagree on what sheepdog write cache
>>> should be.  I think it should work in the same way as a block device
>>> cache, but you think we should limit the usage to simplify the code
>>> and explain what's the limitation in the documentation.  Wuyue's patch
>>> looks necessary from my point of view, but unnecessary to you.  I
>>> don't intend to complain any more because it's you who implements the
>>> current object cache and it should work as you expect.  If I need the
>>> write cache which works like a block device one, I should implement it
>>> as another cache feature.
>>>
>>
>>
>> I've had enough. You and Christoph jump out to bash the object cache
>> time and time again, and seems that never try to read the code to see
>> what is the real culprit and simply ignore or misread my argument.
>>
>> You criticize that object can't handle the mixed writethrough &
>> writeback requests, but it actually does. What cause wrong vdi list
>> output is we don't handle vdi opcode correctly, and I already point to a
> 
> Yes, so I wrote "Some vdi operations don't care about cached data" in
> the commit log.  It's confusing to call requests from
> write_object()/read_object() writethrough, sorry.
> 
>> patch and suggest to 're-visit the patch. well, I think I have clearly
>> stated the intention to merge Wujue's patch(can 're-visit' mean another
> 
> Is it really okay to you?  If yes, I think it's better.
>


Yes, I have talked to Wujue and he will rebase the patch soon.

 
> What I wanted to say is that I wonder we need to have multiple cache
> features, and, with regard to the object cache, I should respect your
> opinion because you are the author.
> 
>> thing?), but 're-visit' makes you complain again that I look like a
>> dictator who never hear your argument.
>>
>> All the way down you and Christoph simply criticize object cache for it
>> can't handle writethrough & writeback requests, which is completely
>> *false* argument. Even if it holds true, I think the best way is to
>> submit a patch to solve the problem and makes it better instead of a
>> simple patch, just to disable it. Yes you can express your dislike about
> 
> No, I don't intend that.
> 
> The object cache is really useful when:
>  - the gateway nodes have much memory
>  - the latency between sheep nodes are high, and it's expensive to
>    replicate data (e.g. use sheepdog with WAN)
> 


Hmm, DIO object cache doesn't need extra client(gateway node) memory,
this should probably be the default option because then it becomes
completely a disk cache that can survive the host crash.

Also I want to mention that, for starting up hundreds of (cloned) Guest
VM concurrently, object cache seems to be a must on a massive nodes
cluster. We also get the benefit that all the cloned VM on the same node
would share large scale of cached objects.

> My suggestion was to disable the object cache by default for now, so I
> wrote "Let's make it default after it becomes stable and mature" in
> the commit log.  If Wujue's patch really fixes all, I have no
> objection to making it default.
> 
>> object cache like this way, now I am completely fine with whatever you
>> like now, feel free to purge object cache from the source code. please
>> voice it out straight if you think so, I don't like to guess on what
>> 'disables it and write another cache' implies.
> 
> I don't intend that I want to disable the object cache and create
> another default one.  I just wanted to say that it's good to have
> another cache with different semantics, and it's safe for all users to
> disable any cache by default.
> 
>>
>>>>
>>>> Anyway, I think now I am fine with adding a new option to disable object
>>>> cache globally, but I don't agree to disable it as default.
>>>
>>> If I can disable it, it's okay to me.  I still think the feature which
>>> doesn't follow the block storage semantics shouldn't be default like
>>> asyncflush, though.
>>
>>
>> isn't asyncflush non-default now? Do I ever complain it is not default?
>> Actually, I guess I also think it is just a interim solution for massive
>> nodes setup. I am surprised you even bring in it as your argument.
>>
>> By writing the email, I come to realize that (I hope it is a false
>> illusion) object cache and Farm doesn't make any sense to you and you
> 
> No, it's just I don't have enough time to look into the code (so sorry
> for that).  It's really good for users to have various options.  My
> opinion is just that the default behavior should be simple, safe, and
> correct as a block device even if it shows poor performance.
> 
>> just forbear voicing it out. Now I am really completely fine with object
>> cache code and Farm purged from source, I am also okay to stop the
>> development of sheepfs, which would be likely annoying according to your
>> standard, because it is virtually another page-cache-like memory cache
>> on the client side, eating up gateway node's memory. I am fond of the
> 
> I've not looked into the sheepfs code yet, sorry.  But I don't intend
> to exclude features which consumes the client-side cache.
> 
>> idea of client-side caching, which seems very wrong to you. Anyway, I am
>> not that into writing the features that I am the only one fond of but
>> annoying to others, fair enough.
> 
> As I said above, the object cache is useful.  I just wanted say that
> it might be better to have another cache feature because which is best
> is up to the user's environment.
> 


Okay, let's all calm down and switch to focus of the development of
Sheepdog.

Thanks,
Yuan