@ph7 [image: 1776271086360-a9ebbee8-7a34-4469-8f48-8b76af15adf6-image.jpeg] let's call it a day @acebmxer after 3 hours the consumption was slightly rising, so we also deployed the latest rest api patch which is already on master : https://github.com/vatesfr/xen-orchestra/commit/0fef765ce6b4bc96b28e6af9be3d3dba3fa7dc1e 0 MathieuRA committed to vatesfr/xen-orchestra fix(rest-api): fix memory-leak on subscription (#9707)

Hello, I see also this behavior which is "new" since few weeks. Previously, when a backup start: it stake a snapshot ( if there another one before, it delete it ). it upload the snapshot as a backup it coalesce the backup on the remote. end of the game. Now, the old snapshots are not deleted anymore which can lead easily to some disk full. Even with a retention of 1, the problem is present. I observe this only in Backup job, not DR/CR job. I just updated my XO to latest version, i will see if the issue is fixed.

@denis.grilli The problem is not the performance of the scan ... the problem is, that this storage device only consists of block devices (disks) that should go into standby mode when not used ... but I think I've found a code line that checks if other-config for an SR contains auto-scan: false... I think ...

@yannsionneau Thanks for the update! We are eagerly awaiting your findings! Thanks for looking into it.

@Pilow Thanks for the heads-up, you should be able to add back concurrency as it was before and get similar performance to before the refactoring.

Hi Vagrantin, If I'm reading this right, the four-slash path is the tell. I can't confirm without seeing your exact Docker invocation, but this pattern points pretty clearly at one thing. misc.sh builds its temp dir from $PWD; something like $PWD/tmpdir-XXXXXX. If Docker is running your build from /, that expands to //tmpdir-XXXXXX. Linux is fine with that. Yum is not. It turns the config path into a file:// URI, and ////tmpdir-VcYHGW/yum-171swX.conf is not a URI anything wants to parse. One other thing worth knowing: a :ro read-only mount on your repo directory causes the same symptom. mktemp fails silently, TMPDIR ends up empty, and you get the same mangled path. Different cause, same four-slash result. Two things to try. The faster diagnostic is just cd into your repo before calling the script: if the build completes, that was it. The cleaner fix for scripted runs is passing -w /path/to/your/repo to your docker run command, which sets the working directory explicitly. Before you do either, this will tell you what you're actually dealing with: echo $PWD && ls -la $TMPDIR That's my best guess, at least. I'm curious what those two commands show.