[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