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