Re: [Qemu-devel] RFC: moving fsfreeze support from the userland guest agent to the guest kernel

[Fernando Luis Vazquez Cao]

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 new
> > > ioctl, FIGETFREEZEFD, which freezes the indicated filesystem and 
> > > returns
> > > a 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=2
> >
> > This 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 cases
>
> One 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