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.
