GGLinnk/bees
1
0
Fork 0
mirror of https://github.com/Zygo/bees.git synced 2025-05-17 21:35:45 +02:00
Code Packages

docs: update the feature interactions page

Browse Source 
Fixing the obviously out-of-date and no-longer-tested things.

Signed-off-by: Zygo Blaxell <bees@furryterror.org>
This commit is contained in:
Zygo Blaxell 2023-02-25 03:09:25 -05:00
parent 3d5ebe4d40
commit f21569e88c
1 changed files with 17 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
docs/btrfs-other.md
View File

@ -8,44 +8,35 @@ bees has been tested in combination with the following:
* HOLE extents and btrfs no-holes feature * HOLE extents and btrfs no-holes feature
* Other deduplicators, reflink copies (though bees may decide to redo their work) * Other deduplicators, reflink copies (though bees may decide to redo their work)
* btrfs snapshots and non-snapshot subvols (RW and RO) * btrfs snapshots and non-snapshot subvols (RW and RO)
* Concurrent file modification (e.g. PostgreSQL and sqlite databases, build daemons) * Concurrent file modification (e.g. PostgreSQL and sqlite databases, VMs, build daemons)
* all btrfs RAID profiles * All btrfs RAID profiles
* IO errors during dedupe (read errors will throw exceptions, bees will catch them and skip over the affected extent) * IO errors during dedupe (read errors will throw exceptions, bees will catch them and skip over the affected extent)
* Filesystems mounted *with* the flushoncommit option ([lots of harmless kernel log warnings on 4.15 and later](btrfs-kernel.md)) * Filesystems mounted with or without the `flushoncommit` option
* Filesystems mounted *without* the flushoncommit option
* 4K filesystem data block size / clone alignment * 4K filesystem data block size / clone alignment
* 64-bit and 32-bit LE host CPUs (amd64, x86, arm) * 64-bit and 32-bit LE host CPUs (amd64, x86, arm)
* Huge files (>1TB--although Btrfs performance on such files isn't great in general) * Large files (kernel 5.4 or later strongly recommended)
* filesystems up to 30T+ bytes, 100M+ files * Filesystems up to 90T+ bytes, 1000M+ files
* btrfs receive * btrfs receive
* btrfs nodatacow/nodatasum inode attribute or mount option (bees skips all nodatasum files) * btrfs nodatacow/nodatasum inode attribute or mount option (bees skips all nodatasum files)
* open(O_DIRECT) (seems to work as well--or as poorly--with bees as with any other btrfs feature) * open(O_DIRECT) (seems to work as well--or as poorly--with bees as with any other btrfs feature)
* lvmcache: no problems observed in testing with recent kernels or reported by users in the last year. * lvm dm-cache, writecache
Bad Btrfs Feature Interactions Bad Btrfs Feature Interactions
------------------------------ ------------------------------
bees has been tested in combination with the following, and various problems are known: bees has been tested in combination with the following, and various problems are known:
* bcache: no data-losing problems observed in testing with recent kernels * btrfs send: there are bugs in `btrfs send` that can be triggered by
or reported by users in the last year. Some issues observed with bees on old kernels. The [`--workaround-btrfs-send` option](options.md)
bcache interacting badly with some SSD models' firmware, but so far works around this issue by preventing bees from modifying read-only
this only causes temporary loss of service, not filesystem damage. snapshots.
This behavior does not seem to be specific to bees (ordinary filesystem
tests with rsync and snapshots will reproduce it), but it does prevent
any significant testing of bees on bcache.
* btrfs send: there are bugs in `btrfs send` that can be triggered by bees.
The [`--workaround-btrfs-send` option](options.md) works around this issue
by preventing bees from modifying read-only snapshots.
* btrfs qgroups: very slow, sometimes hangs...and it's even worse when * btrfs qgroups: very slow, sometimes hangs...and it's even worse when
bees is running. bees is running.
* btrfs autodefrag mount option: hangs and high CPU usage problems * btrfs autodefrag mount option: bees cannot distinguish autodefrag
reported by users. bees cannot distinguish autodefrag activity from activity from normal filesystem activity, and may try to undo the
normal filesystem activity and will likely try to undo the autodefrag autodefrag if duplicate copies of the defragmented data exist.
if duplicate copies of the defragmented data exist.
Untested Btrfs Feature Interactions Untested Btrfs Feature Interactions
----------------------------------- -----------------------------------
@ -54,9 +45,10 @@ bees has not been tested with the following, and undesirable interactions may oc
* Non-4K filesystem data block size (should work if recompiled) * 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) * Non-equal hash (SUM) and filesystem data block (CLONE) sizes (need to fix that eventually)
* btrfs seed filesystems (does anyone even use those?) * btrfs seed filesystems (no particular reason it wouldn't work, but no one has reported trying)
* btrfs out-of-tree kernel patches (e.g. in-kernel dedupe or encryption) * btrfs out-of-tree kernel patches (e.g. in-kernel dedupe, encryption, extent tree v2)
* btrfs-convert from ext2/3/4 (never tested, might run out of space or ignore significant portions of the filesystem due to sanity checks) * btrfs-convert from ext2/3/4 (never tested, might run out of space or ignore significant portions of the filesystem due to sanity checks)
* btrfs mixed block groups (don't know a reason why it would *not* work, but never tested) * btrfs mixed block groups (don't know a reason why it would *not* work, but never tested)
* flashcache: an out-of-tree cache-HDD-on-SSD block layer helper.
* Host CPUs with exotic page sizes, alignment requirements, or endianness (ppc, alpha, sparc, strongarm, s390, mips, m68k...) * Host CPUs with exotic page sizes, alignment requirements, or endianness (ppc, alpha, sparc, strongarm, s390, mips, m68k...)
* bcache: used to be in the "bad" list, now in the "untested" list because nobody is rigorously testing, and bcache bugs come and go
* flashcache: an out-of-tree cache-HDD-on-SSD block layer helper