From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmMQm-0007CH-Uu for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:59:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QmMQl-00031v-RP for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:59:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QmMQl-00031n-Ij for qemu-devel@nongnu.org; Thu, 28 Jul 2011 04:58:59 -0400 Message-ID: <4E312454.90200@redhat.com> Date: Thu, 28 Jul 2011 10:56:52 +0200 From: Jes Sorensen MIME-Version: 1.0 References: <20110727152457.GK18528@redhat.com> <4E303E24.3050800@codemonkey.ws> <20110727183610.GC14736@lst.de> In-Reply-To: <20110727183610.GC14736@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Andrea Arcangeli , Luiz Capitulino , Michael Roth , qemu-devel@nongnu.org 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