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

[MORITA Kazutaka]

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.

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)

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.

Thanks,

Kazutaka