[sheepdog-users] changing cache in run time
Liu Yuan
namei.unix at gmail.com
Tue May 28 11:26:21 CEST 2013
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
More information about the sheepdog-users
mailing list