On 2017-10-19 10:42, Zoltan wrote:
On Thu, Oct 19, 2017 at 4:27 PM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
and thus when the same device reappears (as it will when the disconnect was
due to a transient bus error, which happens a lot), it shows up as a
different device node, which gets scanned for filesystems by udev, and BTRFS
then gets really confused because it now sees 3 (or more) devices for a 2
device filesystem.
And what would happen with a regular, single-device BTRFS volume after
a reconnect? Isn't this issue just as bad for that case?
No, because the multi-device code only gets used if the filesystem
claims to have more than one device, and it's a bug in the multi-device
code that causes this problem. From a data safety perspective, the
disconnect will look like a power loss event if it was a single device
filesystem, and BTRFS handles that situation fine (though you would
probably need to remount the filesystem).
FWIW, the same bug causes similar data loss problems with block-level
copies of BTRFS filesystems (if you then mount either the original or
the copy while both are visible to the system), and allows you to screw
up multi-device filesystems by connecting a storage device with a
carefully crafted bogus BTRFS filesystem on it. Overall though, it's
not been seen as a high priority bug because:
1. Nobody has come up with a reliable method of handling it that doesn't
break anything or require revising the on-disk layout.
2. It's easy to work around (don't do block level copies and ensure
proper physical security of the system like you should be doing anyway).
--
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
