from small one page howto to huge articles all in one place
 

search text in:




Other .linuxhowtos.org sites: www.linuxhowtos.org
toolsntoys.linuxhowtos.org



Last additions:
How to make X listen on port 6000

How to make X listen on port 6000

words:

34

views:

71134

userrating:

average rating: 1.2 (8 votes) (1=very good 6=terrible)


May, 25th 2007:
April, 26th 2007:
Apr, 10th. 2007:
Druckversion . pdf icon
You are here: Portage


Details of sys-fs/bees:

Description: Best-Effort Extent-Same, a btrfs dedup agent
Homepage:
https://github.com/Zygo/bees

available versions:

releasesalphaamd64armhppaia64mipsppcppc64ppc macoss390shsparcx86USE-Flagsdependenciesebuild 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
show
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
show
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
show
Legend:
+ stable
~ testing
- not available
some ebuild warning depend on specific use-flags or architectures, all ebuild-warnings are shown.


back



Support us on Content Nation

New Packages

- as rdf newsfeed
- as rss newsfeed
- as Atom newsfeed
2024-12-21
2024-12-20
rdf newsfeed | rss newsfeed | Atom newsfeed
- Powered by LeopardCMS - Running on Gentoo -
Copyright 2004-2020 Sascha Nitsch Unternehmensberatung GmbH
Valid XHTML1.1 : Valid CSS : buttonmaker
- Level Triple-A Conformance to Web Content Accessibility Guidelines 1.0 -
- Copyright and legal notices -
Time to create this page: 19.2 ms