docs: update btrfs feature interaction status for flushoncommit and SSD caching layers

flushoncommit or not-flushoncommit isn't really a bees matter--it's
a sysadmin's tradeoff between reliability and performance.  bees does
not affect that tradeoff because all dedupe src extents are flushed, so
bees introduces no *new* data loss risks in the noflushoncommit
case--i.e. any data that you could lose while running bees, you'd also
lose when not running bees.

Note that the converse is not true:  bees might trigger flushing on
data that would not normally have been flushed with noflushoncommit,
and improve data integrity after a crash as a side-effect of dedupe
operations.  The risks of noflushoncommit might be reduced by running
bees.  I don't have evidence based on experimental data to support that
conclusion, so I'll just leave this possibility as a rumor in a commit
log message.

lvmcache can be moved from the "bad" list to the "good" list now.

bcache remains in the "bad" list due to some non-data-losing failures
that only seem to happen with bcache.

Add a note about CPUs with strange endianness or page sizes, as nobody
seems to have tried those.

Remove "at great cost" from the btrfs send workaround.  The cost is
the cost, there is no need to editorialize.

Signed-off-by: Zygo Blaxell <bees@furryterror.org>

docs/btrfs-other.md

@@ -11,28 +11,37 @@ bees has been tested in combination with the following:
 * Concurrent file modification (e.g. PostgreSQL and sqlite databases, build daemons)
 * all btrfs RAID profiles
 * 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 (system crashes, power failures OK)
+* Filesystems mounted *with* the flushoncommit option ([lots of harmless kernel log warnings on 4.15 and later](btrfs-kernel.md))
+* Filesystems mounted *without* the flushoncommit option
 * 4K filesystem data block size / clone alignment
-* 64-bit and 32-bit 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)
 * filesystems up to 30T+ bytes, 100M+ files
 * btrfs receive
 * 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)
+* lvmcache:  no problems observed in testing with recent kernels or reported by users in the last year.
 
 Bad Btrfs Feature Interactions
 ------------------------------
 
 bees has been tested in combination with the following, and various problems are known:
 
-* bcache, lvmcache:  **severe (filesystem-destroying) metadata corruption
-  issues** observed in testing and reported by users, apparently only when
-  used with bees.  Plain SSD and HDD seem to be OK.
+* bcache:  no data-losing problems observed in testing with recent kernels
+  or reported by users in the last year.  Some issues observed with
+  bcache interacting badly with some SSD models' firmware, but so far
+  this only causes temporary loss of service, not filesystem damage.
+  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,
-  but possibly at great cost.
+  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
   bees is running.
+
 * btrfs autodefrag mount option:  hangs and high CPU usage problems
   reported by users.  bees cannot distinguish autodefrag activity from
   normal filesystem activity and will likely try to undo the autodefrag
@@ -49,4 +58,5 @@ bees has not been tested with the following, and undesirable interactions may oc
 * btrfs out-of-tree kernel patches (e.g. in-kernel dedupe or encryption)
 * 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)
-* Filesystems mounted *without* the flushoncommit option (don't know the data integrity impact of crashes during dedupe writes vs. ordinary writes)
+* 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...)