On 10/10/2011 11:39 AM, MORITA Kazutaka wrote: > At Sun, 09 Oct 2011 14:27:41 +0800, > Liu Yuan wrote: >> On 10/09/2011 02:21 PM, Yibin Shen wrote: >>> >>> On Sun, Oct 9, 2011 at 1:33 PM, Liu Yuan<namei.unix at gmail.com >>> <mailto:namei.unix at gmail.com>> wrote: >>> >>> On 10/09/2011 01:07 PM, MORITA Kazutaka wrote: >>> >>> At Sun, 9 Oct 2011 11:21:52 +0800, >>> Yibin Shen wrote: >>> >>> Use mmap is much simpler than local backup image, and without >>> any influence to consistency. but it doesn't improve >>> availability >>> while whole sheepdog cluster is die(such as some odd network >>> partition issue). >>> >>> anyway, if no one againsts, I will try to implement it in the >>> near future (after we solved most stability issues) >>> >>> Can we implement it as an extension of the cache mechanism? >>> If the >>> local cache file has whole data in the Sheepdog VDI, we can >>> regard it >>> as a local backup image. >>> >>> Thanks, >>> >>> Kazutaka >>> >>> >>> Maybe we can read-ahead in the whole data if network is not busy >>> gradually? When the whole image is read in, we can mark it as >>> 'complete'. If some time the cluster crashes, the complete image >>> would help the VMs on the very node to survive the crash. The >>> dirty bits will be flushed into cluster store in recovery stage. >>> >>> read-ahead whole image into memory? >>> >> Into file in the local disk, that is supposed to be mmapped into qemu >> process memory. > Is it better to mmap in the gateway sheep daemon (usually, it is a > local sheep daemon)? I think someone want to use Sheepdog from other > than QEMU (e.g. iSCSI target). In addition, we can much more freely > modified Sheepdog server codes than QEMU client ones. > Hmm, yes, it is. Qemu address space just came into my mind without much thought. Thanks, Yuan |