On Tue, Feb 22, 2011 at 02:50:09PM -0600, Anthony Liguori wrote: > >+static int write_commit_file(BdrvCopyState *s) > >+{ > >+ char commit_msg[1400]; > >+ const char *buf = commit_msg; > >+ int len, ret; > >+ > >+ sprintf(commit_msg, "commit QEMU block_copy %s -> %s\n", > >s->src_device_name, > >+ s->dst_filename); > >+ > >+ len = strlen(commit_msg); > >+ while (len> 0) { > >+ ret = write(s->commit_fd, buf, len); > >+ if (ret == -1&& errno == EINTR) { > >+ continue; > >+ } > >+ if (ret<= 0) { > >+ return -errno; > >+ } > >+ buf += ret; > >+ len -= ret; > >+ } > >+ > >+ if (fsync(s->commit_fd) == -1) { > >+ return -errno; > >+ } > > > > This is more or less black magic. What is this commit file used for > and why aren't we using something like a QMP event?
The commit file is considered reliable storage for the result of image switch operation. Think of the following scenario: - mgmt app requests live copy of guests ide1-hd0 from /a/image.img to /b/image.img. - mgmt app dies. - guest switches to /b/image.img, /a/image.img is outdated. - guest dies. Notifying the switch via QMP would not be reliable in this case. Will add this as a comment in the code.