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

[Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>]

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