Kai Krakow

It's in "TOTAL", counter "dedup_bytes" as far as I can tell. But it may not reflect the real value of bytes saved on-disk due to how btrfs internally handles shared...

Well, this is a btrfs on 3x 7200rpm drives with 400G bcache in front of it. And it doesn't look like I see more or less of these performance warnings...

Actually, nothing: ``` # time for x in $(seq -32 32); do btrfs ins log $((x * 4096 + 0x3204ada000)) /run/bees/mnt/26a832d7-73a5-4de5-b272-69f73e1daf5e; done real 2m38,952s user 0m24,895s sys 2m22,522s ``` I...

I think I can pull that statistics from the systemd journal: ``` $ journalctl -u beesd@26a832d7-73a5-4de5-b272-69f73e1daf5e | sed -nr 's/.*PERFORMANCE.*sec:.([^ ]+).*/\1/p' | sort | uniq -dc | sort -nr 59982...

So it seems like on spinning media, "Resolving" and "grow" have "outstanding" bad performance. Not sure about "grow", but "Resolving" probably needs to be optimized in the kernel.

How did you infer the value for `BEES_TOO_LONG`? Because when looking at my numbers, it should be enough to raise it to `2.8` to suppress most of the harmless PERFORMANCE...

I wonder if we could detect `sys/block/*/rotational` to set a sane default... Maybe `2.5 * (rotational + 1)`...

Demoting seems like the best idea... I'm working on configuration files now, so we can get a tuneable later.

I think this is another incarnation of #89 and can be closed in favor of the other issue.

Maybe in short-term, you could create a separate exception class, i.e. "ExitLoopException", catch that, and prevent the stack trace from being printed and just print an informational message received via...