[Sheepdog] Backup/Images

[MORITA Kazutaka]

At Sun, 09 Oct 2011 11:14:11 +0800,
Liu Yuan wrote:
> 
> 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.

I think it is a further feature issue to implement a read-ahead
mechanism in Sheepdog, but sounds interesting (and challenging).

Thanks,

Kazutaka