kakra
commented
3 years ago Just wait. Chances are that CPU time is spent in the kernel, not bees itself (top should show a high SYS% in that case). The kernel will eventually finish the operation after minutes or hours. Bees will mark the affected hash/extent as toxic and not use it again. Using a newer kernel will probably fix it. This is not a problem with read-only snapshots.
You may want to run dmesg from time to time (or run demsg -w to watch for new logs in a terminal): You should see the kernel complaining about seemingly being hung in some tasks for more than 120s (if the soft-lock detector is enabled in your kernel). This isn't critical, it's a symptom of the problem and will resolve cleanly if you just wait long enough.
Zygo
ghost
Reading the filesystem is still ok until there is an attempt to make changes (create new directory, create new file, edit file, rename), at which it soft locks that directory, no read or write request can make to it, any attempt will freeze the client trying to do that.
Powershell creating new directory within directory "Software":
after that, trying to access folder "Software" within Webmin causes infinite load:
bees won't generate new log, rendering the program stuck:
BtrFS is used within Ubuntu VM, running on top of Hyper-V, with disk passthrough. Disk usage can be viewed from Task Manager on Hyper-V host, and there's basically 0% usage and 0kb/s all the time, confirming that deduplication isn't working:
despite not deduplicating anything, bees keeps using CPU all the time,
Filesystem is mounted with option noatime,nodiratime,compress=zstd. Storage setup is RAID-1 from two 2TB hard disk. I'm using Ubuntu 20.04 LTS. Kernel version is 5.4.0.
This issue occurs after a 20GB file was moved to the BtrFS, as you can see in the log screenshot (Ubuntu Server.old.vhdx), and bees runs AFTER a snapshot was created. snapshot is readonly. Perhaps bees is trying to make changes to that readonly snapshot? what should I do next?