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

Liu Yuan namei.unix at gmail.com
Thu May 10 01:55:46 CEST 2012


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

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



More information about the sheepdog mailing list