On 05/28/2013 04:55 PM, Valerio Pachera wrote: > 2013/5/27 Liu Yuan <namei.unix at gmail.com>: >> Dynamic resizing object cache with running VM seems very easy to cause >> problems. Is this feature really needed? > > I was testing it because I saw it was there and to understand if if > was something useful. > >> I can't think of a use case... > > I try to figure some (not because I'm needing it, but for users in general): > - I run a cluster without cache for safety etc etc. > At some point I need a guest to perform fast (maybe just for a day). > In this case it would be good to have the possibility to enable > cache and disable it later without shutting down the cluster. I think it is more fit to have QEMU control it (writeback/writethrough/bypass) object cache from 'cache=' option. This is suggested solution to get finer cache control per VM. So basically, you start sheep with object cache enabled. And You can choose use it (cache=wrtieback/writethrough) or not use it(cache=directsync) when you start VM. Enabled/disable object cache on the fly from collie command is not easy to implement and very likely to cause problems. > - The viceversa. This is actually my production cluster case: it's > running with cache enabled (on all nodes). > Without 'node cache', there's no way to deactivate it in run time. > Starting VM with cache=directsync won't help your case? >> ...because formatted partition can't be sized lively. > > I do not know the relation between cache and partition. > I didn't think there was any. > >> Currently it is only safe to enlarge it dynamically. I am considering of >> removing 'collie node cache'. > > Because it's a cause of troubles, I suggest to remove it for sheepdog 0.6. > If users will request this function, it may worth to reconsider it's > implementation. Agreed. Thanks, Yuan |