[libvirt] [PATCH] qemu: Stop recursive detection of image chains when an image is missing
Peter Krempa
pkrempa at redhat.com
Thu Nov 22 14:12:22 UTC 2012
On 11/22/12 14:44, Eric Blake wrote:
> On 11/22/2012 04:26 AM, Peter Krempa wrote:
>
>>>> +++ b/src/util/storage_file.c
>>>> @@ -729,6 +729,8 @@ virStorageFileGetMetadataFromBuf(int format,
>>>> if (meta->backingStore == NULL) {
>>>> /* the backing file is (currently) unavailable,
>>>> treat this
>>>> * file as standalone */
>>>> + VIR_FREE(meta->backingStoreRaw);
>>
>> Also I should explain the following thing:
>>
>> This freeing of meta->backingStoreRaw actualy doesn't fix the bug. It
>> just felt a right thing to do when the backing file is missing.
>
> Hmm, actually, keeping this around might be nice if someone inspecting
> the chain for missing backing files wants to know that the file was
> missing. But if the same information is also found in
> meta->backingStore, then I guess freeing it is okay (that is, the idea
> is that for a missing backing file, we should be leaving enough
> breadcrumbs for later clients to diagnose what is missing, but also to
> know that it is missing).
The backingStoreRaw would be ideal for this purpose ... well as long as
the callers recognize what's going on.
>
>>
>>>> + meta->backingStoreIsFile = false;
>>
>> This line is the actual fix. The code that recursively detects the image
>> chain uses this value as a marker if another iteration of the recursion
>> is needed (on the non-existing file).
>
> Ah - this line indeed makes sense, then. If we are going to set the
> format as NONE, then we should also mark that it is not a regular file
> (it is a missing file). Keep this change.
>
>>
>>
>>>> backingFormat = VIR_STORAGE_FILE_NONE;
>>>
>>> Hmm, I'm wondering if this is the right place to fix it, or if we are
>>> throwing away information too early. That is, are we sure it is not the
>>> later client of the chain at fault for not recognizing
>>> VIR_STORAGE_FILE_NONE coupled with non-NULL backingStoreRaw as the key
>>> for whether a backing file is missing? I'm guessing
>>> domain_conf.c:virDomainDiskDefForeachPath would be the real function to
>>> fix here.
>>
>> I will add the check also here, but I'd like to discuss the creating of
>> the chain in the first place.
>
> So it sounds like the real fix needs to touch both places - the creation
> of the chain to make sure it leaves enough breadcrumbs, and the
> iteration over the chain to make sure that it handles a missing backing
> file according to the user's wishes (since virDomainDiskDefForeachPath
> has bool ignoreOpenFailure that says whether to ignore a missing file or
> to fail because the chain is incomplete).
>
> I knew this area of code would be tricky when I first started touching it :(
>
It is :) I spent quite a few brain cycles trying to comprehend it. I'll
post a v2 soon.
Peter
More information about the libvir-list
mailing list