mirror of
https://github.com/Zygo/bees.git
synced 2025-05-17 13:25:45 +02:00
ce2521b407
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>