Zygo

@Massimo-B The message you are looking for is `Crawl master ran out of data`. That message is emitted when the search for the next extent from all subvols returns nothing....

Commit 570b3f7de06610c8666a70f2b6e03307d1e382ee introduces support for `SIGTERM` and `SIGINT`. It is now possible to implement a supervisor process (like `timeout`) that kills the bees daemon (with `SIGTERM`), and bees will save...

Optimization eliminates unused code branches entirely, so GCC never gets to warn about their behavior. No warning, no error either. That expression is trying to determine whether it's doing a...

Those options should _minimize_ seeks, though in absolute terms there's still a _lot_ of seeking. Backref lookup iops are mostly cold-cache seeks, and every dedupe operation on btrfs comes with...

dedupe is done when crawl_master emits the "ran out of data" message: crawl_master: Crawl master ran out of data after 0.00975529s, waiting about 2486.09s for transid 21178903...

The string should be in the output somewhere, if it has actually run out of data. It's been in v0.6 since 2018.

If you delete a snapshot while bees is running you will get a burst of those errors because bees will still have cached references to the now-deleted tree. This will...

If you don't give bees subvol 5 you get a different exception: ``` 2019-01-01 21:22:31 4231.4231 bees: btrfs send workaround disabled 2019-01-01 21:22:31 4231.4231 bees: set_root_path /tmp/ 2019-01-01 21:22:31 4231.4231...

In btrfs, extents are immutable. To do dedupe, a solution has to be found that removes every block within an extent, even if they are not duplicate; otherwise, the extent...

It's not just the first block in the sequence--it's the first *matching* block. An extent boundary can appear anywhere, so a matching block can be found at the beginning of...