| from small one page howto to huge articles all in one place
Last additions:
May, 25th 2007:
April, 26th 2007:
Apr, 10th. 2007:
| 
. 
Details of sys-fs/bees:
Description: Best-Effort Extent-Same, a btrfs dedup agent
Homepage: 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
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
|
Legend: + stable~ testing- not availablesome ebuild warning depend on specific use-flags or architectures, all ebuild-warnings are shown.
Tutorials:
no tutorial found
| 
New Packages - as 
- as 
- as 
2024-11-19
2024-11-18
|
- Running on 
-
:
: 