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 |