Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel

[Jes Sorensen <Jes.Sorensen@redhat.com>]

On 07/27/11 20:36, Christoph Hellwig wrote:
> Initiating the freeze from kernelspace doesn't make much sense.  With
> virtio we could add in-band freeze request to the protocol, and although
> that would be a major change in that way virtio-blk works right now it's
> at least doable.  But all other "real" storage targets only communicate
> with their initators over out of band procotols that are entirely handled
> in userspace, and given their high-level nature better are - that is if
> we know them at all given how vendors like to keep this secrete IP
> closed and just offer userspace management tools in binary form.
> 
> building new infrastructure in the kernel just for virtio, while needing
> to duplicate the same thing in userspace for all real storage seems like
> a really bad idea.  That is in addition to the userspace freeze notifier
> similar to what e.g. Windows has - if the freeze process is driven from
> userspace it's much easier to handle those properly compared to requiring
> kernel upcalls.
> 

The freeze operation would really just be a case of walking the list of
mounted file systems and calling the FIFREEZE ioctl operation on them. I
wouldn't anticipate doing anything else in a virtio-fsfreeze.ko module.

Cheers,
Jes