huge number of api call "sr.getAllUnhealthyVdiChainsLength" in tasks

[manilx]

@manilx Was fine for a short while only: https://xcp-ng.org/forum/topic/9275/starting-getting-again-retry-the-vm-backup-due-to-an-error-error-vdi-must-be-free-or-attached-to-exactly-one-vm

[rvreugde]

Same problem here 300+ sessions and counting

XAPI restart did not solve the issue...

[ryan.gravel]

Doesn't seem to be respecting [NOBAK] anymore for storage repos. Tried '[NOSNAP][NOBAK] StorageName' and it still grabs it.

[olivierlambert]

On the VDI name, right?

[ryan.gravel]

@olivierlambert I believe so. It is the Disks tab of a VM. [NOBAK] was working but now the NAS is complaining about storage space. This VM has a disk on the NAS so it is backing it up twice. Added [NOSNAP] just as a test with the same result.

It is running a full backup if that makes any difference.

[olivierlambert]

Ping @julien-f

[julien-f]

@ryan-gravel I cannot reproduce, both Full Backup and Incremental Backup correctly ignore VDIs with [NOBAK] in their name label.

[Andrew]

@julien-f It's happening to me too... my [NOBAK] disk is being backed up now (commit 0e4a3) using the normal Backup (running a full).

[ryan.gravel]

@Andrew @julien-f Ran a full backup with commit 96b76 and it is working properly now. Started thinking that I was the only one Thanks a lot for everyone's help!

[Andrew]

With today's update (feat: release 5.96.0, master 96b7673) things are working well again. I have not seen any Orphan VDI/snapshots or stuck Control Domain VDIs (but it may take time to test). Thanks to the Vates team!

[julien-f]

Hello, can you please try the buffered-task-events branch and let me know if that solves the issue?