Kai Krakow

You should also purge the crawl state in this case so it will start from the beginning. Otherwise it will miss all dedup candidates which previously didn't fit into the...

> ERROR: /boot/.beeshome MUST BE A SUBVOL! I think this is a bug in the beesd launcher script: It insists on `$BEESHOME` being a sub volume. That's not really a...

So a fixed script should allow any directory for beeshome on file systems distinct from the volume targeted by bees, otherwise it should probably insist on it being a subvol:...

I think you can ignore this. An uneducated guess is that the extent position has changed on disk between bees submitting it to the dedup queue and actually deduping it....

> 1. How do I check what the `zstd` compression on `sv2` actually got me? You cannot actually mount the same btrfs with different compression options even when it's different...

It's probably stuck in an uninterruptable state (status "D" in top). You should try if you could get a stacktrace somehow. If your kernel is configured for this, you should...

So it's actually no longer running already (zombie). You cannot kill what's already dead. ;-) Look in pstree: 1. What is the parent process? `pstree -ps $(pidof bees)` 2. Which...

@Massimo-B A zombie process will not be cleaned up unless it's parent has read the exit status. Actually, in your case the beesd script was locked up, probably during the...

Did you have autodefrag running while the VM was active?

@Massimo-B wrote: > I got around the issue by just deleting those snapshots of the Virtual Machines as kakra mentioned. Let's not break media here... I mentioned this on IRC....