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

[Andrea Arcangeli <aarcange@redhat.com>]

On Wed, Jul 27, 2011 at 08:36:10PM +0200, 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.

I don't see how blkdev are related or how virtio-blk is related to
this. Clearly there would be no ring for this, just a paravirt driver
calling into the ioctl_fsfreeze().

What would those "real" storage targets be? It's just a matter of
looping on the superblocks and call freeze_super() on those if
sb->s_op->freeze_fs is not null. We don't even need to go through a
fake file handle to reach the fs by doing it in the guest kernel.

> building new infrastructure in the kernel just for virtio, while needing

It doesn't need to be virtio as in ring. Maybe I should have called it
paravirt-fsfreeze (as in PARAVIRT_CLOCK), virtio as in doing I/O not.

> 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.

Not sure how it is simpler to talk through a virtio-serial some
protocol than to poll a /dev/fsfreeze or /dev/paravirt-fsfreeze.