On Tue, 2009-04-07 at 14:32 -0700, Javier Guerra wrote:
> On Tue, Apr 7, 2009 at 4:12 PM, Kevin Fox <Kevin.Fox@xxxxxxx> wrote:
> > So, in a single kernel (2.6.29+), lvm can tell the file system using
> the
> > block device to freeze so it can take its snapshot, and then tell it
> to
> > unfreeze. How hard would this be to extend this so that an LVM
> sitting
> > in Dom0 could forward the freeze calls to DomU? Say, through the
> virtual
> > block devices. You could then run your backups in Dom0 instead of
> every
> > DomU. This would save you on per client licensing fees.
>
> AFAICT, it has nothing to do with the block device. it's a new
> feature that some filesystems might choose to implement, to establish
> a point in time where the filesystem is safely snapshottable without
> preserving RAM state.
Ah, I see. I misread this part:
"Essentially the patch just exports the freeze_bdev() kernel function in
a user accessible way."
It implements it as an ioctl to a fd for the mount point of the file
system. I thought it was passed a block device. My bad.
So it looks like its up to the lvm snapshot utility to find the
filesystem in question if mounted, do the freeze ioctl, do the snapshot
and then run the unfreeze ioctl?
To support this, the lvm snapshot tool would have to know that the block
device was used by a xen/qemu session and forward the freeze/unfreeze
through.
> XFS has had this feature (and some extra bells/whistles) for years; i
> don't know if any non-SGI backup system uses it.
>
> in any case, if you want it to be initiated on Dom0, it has to signal
> the DomU to do all the freezing. also, it might not flush caches to
> the blockdevice, since it might assume that the snapshot is done over
> the cache layer (ie. by LVM in the same machine, not the Dom0 'beneath
> it').
I glanced at the code last week, and I think I remember it doing a sync
to the block device, but don't quote me on that. :) So it should flush
the caches.
>
> >> 2: it does nothing about complex applications with their own caches
> >> and file structures: IOW, databases. if you get an 'in VM'
> snapshot
> >> capability, you still have to flush caches and suspend operations
> for
> >> the snapshot.
> >
> > A lot of backup systems I've seen tough, largely just save the
> files, or
> > ignore them if they are written while saving. They don't bother to
> flush
> > caches and suspend. It doesn't work for everything (databases), but
> for
> > most applications it is fine. One example use case would be each
> users
> > desktop session gets a virtual machine. You could backup the users
> data
> > without needing to have a backup client in the vm.
>
> if you're willing to forgive databases and similar loads, a simple LVM
> snapshot is more than enough. any current journal FS will easily
> regain integrity.
Not exactly. I think the whole ext4 uber thread on
create/write/rename/no fsync thing showed that there are cases when that
can have bad results. I think your pretty safe doing it with ext3 (but
there was some mention of a 5 second window that may be a problem).
Kevin
> heck, for desktop users' data just do rsync to a central location and
> be done! (extra points if using rsnapshot to keep several 'snapshots')
>
>
> --
> Javier
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home