On 10/09/2011 01:01 AM, MORITA Kazutaka wrote: > At Sat, 8 Oct 2011 11:12:00 +0800, > Yibin Shen wrote: >> we have talked about similar topic in the past weeks. >> >> IMO, let sheepdog support local backup image will promote the availability effectively, >> the local backup image is located in the machine where vm runs, >> then writeback policy is adopted just like what qcow/qcow2's backup image do. >> >> the storage size issue can be solved through decrease the number of copies. >> >> benefits: >> 1)network traffic will be reduced, which will also make corosync work more stable. >> 2)even whole sheepdog cluster crashed, the local image can still provide service. >> >> tradeoffs: >> 1)stronge consistency is damaged for I/O is not triggered synchronously now. >> to solve this problem, at least we need maintain a journal for local backup image. >> 2)migration of vm will became much more complicated. >> >> so, maybe this is only a transitionary solution before sheepdog archive industry available standard. > Someone suggested a bit similar idea before. The idea is: > > - A VM use a local mmaped file as a disk cache of a Sheepdog volume. > - Write requests are regarded as completed when the data are written > to the mmap address (write-back). > - If the VM sends a sync request, its response will be blocked until > the data is replicated to multiple storage nodes. > Sounds feasible. Cache is quite common method that is mostly implemented in client side of distributed system, to boost performance. The mmapped implementation would be the simplest one to work out a cache mechanism. This pushes cache logic proper into kernel mm subsystem and simply use some system calls to achieve the write-back. I am not sure if we need to implement a read-ahead mechanism after write-back being implemented. This need more data analysis to support it if necessary, though most Guest OSes implement a read-ahead mechanism internally. Thanks, Yuan > I think this improves a performance significantly, especially when > network latency is high (e.g. WAN environment). The data consistency > is not a problem if sync requests ensure that the data is replicated. > > To support this idea, we need to support a write-back mode in > Sheepdog; we need to add a sync operation to Sheepdog protocols and > implement bdrv_co_flush() in the Sheepdog QEMU block driver. > > > Thanks, > > Kazutaka > |