gentoo.LinuxHowtos.org
Details of sys-fs/bees:
Description: Best-Effort Extent-Same, a btrfs dedup agentHomepage: https://github.com/Zygo/bees
available versions:
releases | alpha | amd64 | arm | hppa | ia64 | mips | ppc | ppc64 | ppc macos | s390 | sh | sparc | x86 | USE-Flags | dependencies | ebuild warnings |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
bees-9999 | - | - | - | - | - | - | - | - | - | - | - | - | - | none | show | With kernel versions below 4.11, bees may severely degrade system performance and responsiveness. Especially, the kernel may deadlock while bees is running, it's recommended to run at least kernel 4.11. With kernel versions below 4.14.29, bees may generate a lot of bogus WARN_ON() messages in the kernel log. These messages can be ignored and this is fixed with more recent kernels: # WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 With kernel versions below 5.4.96 and 5.7, the kernel may hold file system locks for a long time while at the same time CPU usage increases when bees is operating. bees tries to avoid this behavior by excluding very common extents from deduplication. This has only a minimal impact on dedupe effectiveness. IMPORTANT: With kernel versions below 5.1.0, you may experience data corruption due to bees using compression in btrfs. You are adviced to use a chronologically later kernel, that includes older LTS versions released after 5.0.4: Fixed in: 5.1+, 5.0.4+, 4.19.31+, 4.14.108+, 4.9.165+, 4.4.177+, 3.18.137+ # commit 8e92821 btrfs: fix corruption reading shared and compressed extents after hole punching With kernel versions below 5.4.19, bees may trigger a btrfs bug when running btrfs-balance in parallel. This may lead to meta-data corruption in the worst case. Especially, kernels 5.1.21 and 5.2.21 should be avoided. Kernels 5.0.x after 5.0.21 should be safe. In the best case, affected kernels may force the device RO without writing corrupted meta-data. More details: https://github.com/Zygo/bees/blob/master/docs/btrfs-kernel.md With kernel versions 5.15.107 or later, there is a memory fragmentation issue with LOGICAL_INO which can lead to cache thrashing and cause IO latency spikes. This version ships with a work-around at the cost of not handling highly duplicated filesystems that well. More details: https://github.com/Zygo/bees/issues/260 WARNING: Kernel versions lower than 5.7 are no longer really supported by bees. While there should be no unexpected data loss, you may experience severe slowdowns or even system lockups. Bees recommends running the latest current kernel for performance and |
bees-0.10-r1 | - | - | - | - | - | - | - | - | - | - | - | - | - | none | show | With kernel versions below 4.11, bees may severely degrade system performance and responsiveness. Especially, the kernel may deadlock while bees is running, it's recommended to run at least kernel 4.11. With kernel versions below 4.14.29, bees may generate a lot of bogus WARN_ON() messages in the kernel log. These messages can be ignored and this is fixed with more recent kernels: # WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 With kernel versions below 5.4.96 and 5.7, the kernel may hold file system locks for a long time while at the same time CPU usage increases when bees is operating. bees tries to avoid this behavior by excluding very common extents from deduplication. This has only a minimal impact on dedupe effectiveness. IMPORTANT: With kernel versions below 5.1.0, you may experience data corruption due to bees using compression in btrfs. You are adviced to use a chronologically later kernel, that includes older LTS versions released after 5.0.4: Fixed in: 5.1+, 5.0.4+, 4.19.31+, 4.14.108+, 4.9.165+, 4.4.177+, 3.18.137+ # commit 8e92821 btrfs: fix corruption reading shared and compressed extents after hole punching With kernel versions below 5.4.19, bees may trigger a btrfs bug when running btrfs-balance in parallel. This may lead to meta-data corruption in the worst case. Especially, kernels 5.1.21 and 5.2.21 should be avoided. Kernels 5.0.x after 5.0.21 should be safe. In the best case, affected kernels may force the device RO without writing corrupted meta-data. More details: https://github.com/Zygo/bees/blob/master/docs/btrfs-kernel.md With kernel versions 5.15.107 or later, there is a memory fragmentation issue with LOGICAL_INO which can lead to cache thrashing and cause IO latency spikes. This version ships with a work-around at the cost of not handling highly duplicated filesystems that well. More details: https://github.com/Zygo/bees/issues/260 Bees recommends running the latest current kernel for performance and |
bees-0.10 | - | - | - | - | - | - | - | - | - | - | - | - | - | show | With kernel versions below 4.11, bees may severely degrade system performance and responsiveness. Especially, the kernel may deadlock while bees is running, it's recommended to run at least kernel 4.11. With kernel versions below 4.14.29, bees may generate a lot of bogus WARN_ON() messages in the kernel log. These messages can be ignored and this is fixed with more recent kernels: # WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 With kernel versions below 5.4.96 and 5.7, the kernel may hold file system locks for a long time while at the same time CPU usage increases when bees is operating. bees tries to avoid this behavior by excluding very common extents from deduplication. This has only a minimal impact on dedupe effectiveness. IMPORTANT: With kernel versions below 5.1.0, you may experience data corruption due to bees using compression in btrfs. You are adviced to use a chronologically later kernel, that includes older LTS versions released after 5.0.4: Fixed in: 5.1+, 5.0.4+, 4.19.31+, 4.14.108+, 4.9.165+, 4.4.177+, 3.18.137+ # commit 8e92821 btrfs: fix corruption reading shared and compressed extents after hole punching With kernel versions below 5.4.19, bees may trigger a btrfs bug when running btrfs-balance in parallel. This may lead to meta-data corruption in the worst case. Especially, kernels 5.1.21 and 5.2.21 should be avoided. Kernels 5.0.x after 5.0.21 should be safe. In the best case, affected kernels may force the device RO without writing corrupted meta-data. More details: https://github.com/Zygo/bees/blob/master/docs/btrfs-kernel.md With kernel versions 5.15.107 or later, there is a memory fragmentation issue with LOGICAL_INO which can lead to cache thrashing and cause IO latency spikes. This version ships with a work-around at the cost of not handling highly duplicated filesystems that well. More details: https://github.com/Zygo/bees/issues/260 Bees recommends running the latest current kernel for performance and |
+ stable
~ testing
- not available
some ebuild warning depend on specific use-flags or architectures, all ebuild-warnings are shown.