On 05/11/2012 04:06 AM, MORITA Kazutaka wrote: > At Fri, 11 May 2012 00:31:49 +0800, > Liu Yuan wrote: >> >> On 05/10/2012 10:37 PM, Christoph Hellwig wrote: >> >>>> What did you mean by en/disable it on a per VDI basis? I think object >>>>> cache does have this attribute, in terms of QEMU command line option. Or >>>>> I miss some context? >>> Have an attribute on the sheepdog_inode that the object cache is used >>> for access to this VDI, without having to coordinate all possible users >>> of it, e.g. a way to specify it when creating the vdi and having any >>> user simpliy do the right thing. >> >> I don't think it make any sense. This just complicate the things, for >> now we have a global switch and per VDI switch already, any attempt to >> introduce yet another switch looks really crazy to me. Maybe it would > > If we allow multiple cache features in future, I think it makes sense > to have such attribute because we cannot specify the detailed cache > control in the qemu command line options. It enables us to provide > different cache levels according to the customer demand. > I am not against introducing another cache mechanism if considered necessary. Let's find the best default option when other cache feature is actually implemented. Thanks, Yuan >> help your use case, but I think you should be aware: >> >> 1) Sheepdog originally targets for mixing computing and storage in one >> cluster to maximize the resource usage. >> 2) Sheepdog isn't inherently optimized for users who has extremely >> high-end and fast network. > > Yes, Sheepdog aimed at that. However, currently there are already > some users (one of them belongs to our NTT group) who want to use > Sheepdog without mixing computing and storage resources or try > Sheepdog with non-commodity hardware like Fusion-io or Infiniband. > As a sheepdog maintainer, I'd like to accept these requirements if it > doesn't bring much complexity to Sheepdog design and implementation. > > Anyway, it's okay to me to enable the object cache by default if it > fits for 1) and 2) (I think we should document this restriction more > clearly for users not to enable it wrongly), but want to see other > cache features which fit for other requirements, too. > |