|
From: | Fernando Luis Vazquez Cao |
Subject: | Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel |
Date: | Fri, 29 Jul 2011 09:29:09 +0900 |
User-agent: | Thunderbird 2.0.0.16 (Windows/20080708) |
Michael Roth さんは書きました:
On 07/28/2011 03:03 AM, Andrea Arcangeli wrote:On Thu, Jul 28, 2011 at 11:53:50AM +0900, Fernando Luis Vázquez Cao wrote:On Wed, 2011-07-27 at 17:24 +0200, Andrea Arcangeli wrote:making sure no lib is calling any I/O function to be able to defreeze the filesystems later, making sure the oom killer or a wrong kill -9 $RANDOM isn't killing the agent by mistake while the I/O is blocked and the copy is going.Yes with the current API if the agent is killed while the filesystems are frozen we are screwed. I have just submitted patches that implement a new API that should make the virtualization use case more reliable. Basically, I am adding a newioctl, FIGETFREEZEFD, which freezes the indicated filesystem and returnsa file descriptor; as long as that file descriptor is held open, the filesystem remains open. If the freeze file descriptor is closed (be it through a explicit call to close(2) or as part of process exit housekeeping) the associated filesystem is automatically thawed. - fsfreeze: add ioctl to create a fd for freeze control http://marc.info/?l=linux-fsdevel&m=131175212512290&w=2 - fsfreeze: add freeze fd ioctls http://marc.info/?l=linux-fsdevel&m=131175220612341&w=2This is probably how the API should have been implemented originally instead of FIFREEZE/FITHAW. It looks a bit overkill though, I would think it'd be enough to have the fsfreeze forced at FIGETFREEZEFD, and the only way to thaw by closing the file without requiring any of the FS_FREEZE_FD/FS_THAW_FD/FS_ISFROZEN_FD. But I guess you have use casesOne of the crappy things about the current implementation is the inability to determine whether or not a filesystem is frozen. At least in the context of guest agent at least, it'd be nice if guest-fsfreeze-status checked the actual system state rather than some internal state that may not necessarily reflect reality (if we freeze, and some other application thaws, we currently still report the state as frozen).Also in the context of the guest agent, we are indeed screwed if the agent gets killed while in a frozen state, and remain screwed even if it's restarted since we have no way of determining whether or not we're in a frozen state and thus should disable logging operations.
That is precisely the reason I added the new API.
We could check status by looking for a failure from the freeze operation, but if you're just interested in getting the state, having to potentially induce a freeze just to get at the state is really heavy-handed.So having an open operation that doesn't force a freeze/thaw/status operation serves some fairly common use cases I think.
Yep. If you think there is something missing API wise let me know and I will implement it.
Thanks, Fernando
[Prev in Thread] | Current Thread | [Next in Thread] |