From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmA5O-0003y6-G7 for qemu-devel@nongnu.org; Wed, 27 Jul 2011 15:48:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmA5N-0003lr-7s for qemu-devel@nongnu.org; Wed, 27 Jul 2011 15:48:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmA5M-0003lG-Mo for qemu-devel@nongnu.org; Wed, 27 Jul 2011 15:48:05 -0400 Date: Wed, 27 Jul 2011 21:47:58 +0200 From: Andrea Arcangeli Message-ID: <20110727194758.GD3087@redhat.com> References: <20110727152457.GK18528@redhat.com> <4E303E24.3050800@codemonkey.ws> <20110727183610.GC14736@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110727183610.GC14736@lst.de> Subject: Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Jes Sorensen , Luiz Capitulino , Michael Roth , qemu-devel@nongnu.org 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.