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

Re: [libvirt] [RFC] Add a new feild to qemud_save_header to tell if the saved image is corrupt

于 2011年08月17日 22:12, Eric Blake 写道:
On 08/17/2011 07:10 AM, Osier Yang wrote:
If one tries to restore a domain from a corrupt save image, we blindly
goes forward to restore from it, this can cause many different errors,
depending on how much the image is saved. E.g.


So I'm thinking if we can introduce a new feild to struct qemud_save_header, such as "bool complete;", and set it true if succeeded to save the image, false if not. So that could do some checking while trying to open the image
(qemuDomainSaveImageOpen), and quit early if "complete" is false, with
a sensiable error message.

Almost. I think we can reuse one of the existing spare fields in the header (that is, change unused[15] to instead be unused[14] and make the new field a uint32_t), and I also think we need to have a tri-state value:

0 - save image was created with older libvirt, no idea if image is sane
1 - save image created by current libvirt, but not yet marked complete; attempts to restore from this image should fail with sensible message suggesting nuking the save image since it is broken - value written at start of save process 2 - save image created by current libvirt and completed - value written at end of save process

And of course, we have to update the bswap_header routine to treat it with the same endianness as the rest of the header.


Sounds reasonable. I don't even think we have to bump the qemud_save_header version (that is, older libvirt will ignore the field, and the size is not changing, and newer libvirt will correctly handle the situation where the field was not set).

Agree on using the "unused[14]", with this we don't need to care
about the C/S communications (between older and newer, or newer
and older). Thanks for this good thought. :)

The toughest part will be figuring out how to modify the field when using an O_DIRECT fd. I guess here, we write the entire file O_DIRECT, then when qemu completes the save, we close the fd, and open a new one that is not O_DIRECT, since we will be polluting the cache with only one sector of the file, rather than having to worry about O_DIRECT pickiness (the main point of O_DIRECT was for the benefit to the much larger portion of the file written by qemu).

Not quite understand here, what I can get is opening the file with
O_DIRECT will cause the dirty cache will be flushed to disk before
every following read/write. What pollutes the cache?

Agree on reopening the save file without O_DIRECT to modify the
feild though.


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