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. >> 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 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. I think we are coding sheepdog for general setup, where we have low-end servers with ordinary network connect and try to cluster them together to get a better utilized and elastic computing and storage. I think with current global and per VDI switch for object cache, nothing technically stops you from achieving your personal target at your own will. Thanks, Yuan |