Austin S. Hemmelgarn posted on Tue, 17 Oct 2017 15:19:09 -0400 as excerpted:
>> It's a single-device filesystem, thus disconnects are obviously fatal. >> But, >> they never caused even a single bit of damage (as scrub goes), thus >> proving btrfs handles this kind of disconnects well. Unlike times >> past, the kernel doesn't get confused thus no reboot is needed, merely >> an unmount, "service nbd-client restart", mount, restart the rebuild >> jobs. > That's expected behavior though. _Single_ device BTRFS has nothing to > get out of sync most of the time, the only time there's any possibility > of an issue is when you die after writing the first copy of a block > that's in a dup profile chunk, but even that is not very likely to cause > problems (you'll just lose at most the last <commit-time> worth of > data). The moment you add another device though, that simplicity goes > out the window. This is why I said if you /must/ work with USB-connected devices, I'd suggest single-device btrfs, tho I'd go full dup (data too) to take advantage of the btrfs ability to detect checksum errors and rewrite a bad copy from the second, hopefully good, copy. Single device simply doesn't have the sync issues of multi-device, even in dup mode, so end up being much more reliable in cases like USB connection (and NBD as in the example above), where connection reliability is a problem. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
