mirror of
https://github.com/Zygo/bees.git
synced 2025-05-17 13:25:45 +02:00
Tested on larger filesystems than 100T too, but let's use Fermi approximation. Next size is 1P. Removed interaction with block-level SSD caching subsystems. These are really btrfs metadata vs. a lower block layer, and have nothing to do with bees. Added mixed block groups to the tested list, as mixed block groups required explicit support in the extent scanner. Added btrfs-convert to the tested list. btrfs-convert has various problems with space allocation in general, but these can be solved by carefully ordered balances after conversion, and they have nothing to do with bees. In-kernel dedupe is dead and the stubs were removed years ago. Remove it from the list. btrfs send now plays nicely with bees on all supportable kernels, now that stable/linux-4.19.y is dead. Send workaround is only needed for kernels before v5.4 (technically v5.2, but nobody should ever mount a btrfs with kernel v5.1 to v5.3). bees will pause automatically when deduping a subvol that is currently running a send. bees will no longer gratuitously refragment data that was defragmented by autodefrag. Explicitly list all the RAID profiles tested so far, as there have been some new ones. Explicitly list other deduplicators tested. Sort the list of btrfs features alphabetically. Add scrub and balance, which have been tested with bees since the beginning. New tested btrfs features: block-group-tree, raid1c3, raid1c4. New untested btrfs features: squotas, raid-stripe-tree. Signed-off-by: Zygo Blaxell <bees@furryterror.org>
2.2 KiB
2.2 KiB
Good Btrfs Feature Interactions
bees has been tested in combination with the following:
- btrfs compression (zlib, lzo, zstd)
- PREALLOC extents (unconditionally replaced with holes)
- HOLE extents and btrfs no-holes feature
- Other deduplicators (
duperemove
,jdupes
) - Reflink copies (modern coreutils
cp
andmv
) - Concurrent file modification (e.g. PostgreSQL and sqlite databases, VMs, build daemons)
- All btrfs RAID profiles: single, dup, raid0, raid1, raid10, raid1c3, raid1c4, raid5, raid6
- IO errors during dedupe (affected extents are skipped)
- 4K filesystem data block size / clone alignment
- 64-bit and 32-bit LE host CPUs (amd64, x86, arm)
- Large files (kernel 5.4 or later strongly recommended)
- Filesystem data sizes up to 100T+ bytes, 1000M+ files
open(O_DIRECT)
(seems to work as well--or as poorly--with bees as with any other btrfs feature)- btrfs-convert from ext2/3/4
- btrfs
autodefrag
mount option - btrfs balance (data balances cause rescan of relocated data)
- btrfs block-group-tree
- btrfs
flushoncommit
andnoflushoncommit
mount options - btrfs mixed block groups
- btrfs
nodatacow
/nodatasum
inode attribute or mount option (bees skips all nodatasum files) - btrfs qgroups and quota support (not squotas)
- btrfs receive
- btrfs scrub
- btrfs send (dedupe pauses automatically, kernel 5.4 or later required)
- btrfs snapshot, non-snapshot subvols (RW and RO), snapshot delete
Note: some btrfs features have minimum kernel versions which are higher than the minimum kernel version for bees.
Untested Btrfs Feature Interactions
bees has not been tested with the following, and undesirable interactions may occur:
- Non-4K filesystem data block size (should work if recompiled)
- Non-equal hash (SUM) and filesystem data block (CLONE) sizes (need to fix that eventually)
- btrfs seed filesystems, raid-stripe-tree, squotas (no particular reason these wouldn't work, but no one has reported trying)
- btrfs out-of-tree kernel patches (e.g. encryption, extent tree v2)
- Host CPUs with exotic page sizes, alignment requirements, or endianness (ppc, alpha, sparc, strongarm, s390, mips, m68k...)