qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest ag


From: Jes Sorensen
Subject: Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel
Date: Thu, 28 Jul 2011 10:56:52 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc14 Thunderbird/3.1.11

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]