On Fri, Aug 28, 2020, 08:36 Germano Veit Michel <[email protected]> wrote:

>
>
> On Fri, Aug 28, 2020 at 9:29 AM Nir Soffer <[email protected]> wrote:
>
>>
>>
>> On Thu, Aug 27, 2020, 16:38 Tal Nisan <[email protected]> wrote:
>>
>>>
>>>
>>> On Fri, Aug 21, 2020 at 4:34 AM Germano Veit Michel <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is there a reliable way to figure out if a snapshot is in preview only
>>>> using information obtained from the storage domain metadata?
>>>> I'm trying to find a way to distinguish a problematic snapshot chain
>>>> (double parent) from a snapshot in preview in order to improve dump-volume
>>>> chains.
>>>>
>>>> Currently dump-volume-chains throws an error (DuplicateParentError) if
>>>> a snapshot is in preview for the image, as there is a 'Y' shape split in
>>>> the chain
>>>> with 2 volumes (previous chain + preview) pointing to a common parent:
>>>>
>>>>    image:    dff0a0c0-b731-4e5b-9f32-d97310ca40de
>>>>
>>>>              Error: more than one volume pointing to the same parent
>>>> volume e.g: (_BLANK_UUID<-a), (a<-b), (a<-c)
>>>>
>>>>              Unordered volumes and children:
>>>>
>>>>              - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <-
>>>> 5eb2b29d-82d6-4337-8511-3c86705d566e
>>>>                status: OK, voltype: LEAF, format: COW, legality: LEGAL,
>>>> type: SPARSE, capacity: 1073741824, truesize: 1073741824
>>>>
>>>>              - e0475853-4514-4464-99e7-b185cce9b67d <-
>>>> deceff83-9d88-4f87-8304-d5bf74d119b1
>>>>                status: OK, voltype: LEAF, format: COW, legality: LEGAL,
>>>> type: SPARSE, capacity: 1073741824, truesize: 1073741824
>>>>
>>>>              - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <-
>>>> e0475853-4514-4464-99e7-b185cce9b67d
>>>>                status: OK, voltype: INTERNAL, format: COW, legality:
>>>> LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824
>>>>
>>>>              - 00000000-0000-0000-0000-000000000000 <-
>>>> e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38
>>>>                status: OK, voltype: INTERNAL, format: RAW, legality:
>>>> LEGAL, type: PREALLOCATED, capacity: 1073741824, truesize: 1073741824
>>>>
>>>> From the engine side it's easy, but I'd need to solve this problem
>>>> using only metadata from the storage.
>>>>
>>>> The only thing I could think of is that one of the volumes pointing to
>>>> the common parent has voltype LEAF. Any better ideas?
>>>>
>>> don't think that there is any, Engine is the orchestrator and due to
>>> that the info is only in the database
>>>
>>
>> There is no good way, but you can look at the length of the chain, and
>> the "ctime" value.
>>
>> For example if this was the original chain:
>>
>> a <- b <- c
>>
>> if we preview a:
>>
>> a <- b <- c
>> a <- d
>>
>> You know that d is a preview volume.
>>
>> If we preview b, we will have two chains of same length:
>>
>> a <- b <- c
>> a <- b <- d
>>
>> But the ctime value of d will be larger, since preview is created after
>> the leaf was created.
>>
>> ctime is using time.time() so it is not affected by time zone changes
>> but it may be wrong due to host time changes, so it is not reliable.
>>
>> Can you open a bug for this?
>>
> https://bugzilla.redhat.com/show_bug.cgi?id=1873382
>
> I have a prototype working with some code I pasted in the bugzilla, but I
> don't think it's reliable and an overcomplication of what should be simple.
>

I don't think the code in the bug is the way to handle this.

It will be simpler and more useful to:
1. Find leaves
2. Follow the chain from each leaf, until the base (volume with no parent).
3. Display a tree instead of list, like lsblk.

For example:

dbf1e90c-41d5-4c2d-a8d2-15f2f04d3561
├─ea6af566-922c-4ca2-af17-67f7cd08826c
└─aa5643ef-8c74-4b28-91e0-8d45d6ee426b
  └─30c4f6d1-7f1d-470b-96ae-7594cf367dfa

Users of the tool will have to check engine db to understand how to fix the
disk.

Even if it was easy to detect a volume in preview, how do you know which
chain
should be kept? Did it fail just after the user asked to commit the preview?

Storage format does not have a way to store info about the state of the
disk, or make atomic
changes like remove one chain when committing after a preview. This is also
the reason we
have trouble with removing snapshots.

Nir


>
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/[email protected]/message/6FPW4GDSHUG3UPJTSFY4GYAZFCEASXMW/

Reply via email to