Marc Lehmann posted on Wed, 06 Jun 2018 21:06:35 +0200 as excerpted: > Not sure what exactly you mean with btrfs mirroring (there are many > btrfs features this could refer to), but the closest thing to that that > I use is dup for metadata (which is always checksummed), data is always > single. All btrfs filesystems are on lvm (not mirrored), and most (but > not all) are encrypted. One affected fs is on a hardware raid > controller, one is on an ssd. I have a single btrfs fs in that box with > raid1 for metadata, as an experiment, but I haven't used it for testing > yet.
On the off chance, tho it doesn't sound like it from your description... You're not doing LVM snapshots of the volumes with btrfs on them, correct? Because btrfs depends on filesystem GUIDs being just that, globally unique, using them to find the possible multiple devices of a multi-device btrfs (normal single-device filesystems don't have the issue as they don't have to deal with multi-device as btrfs does), and btrfs can get very confused, with data-loss potential, if it sees multiple copies of a device with the same filesystem GUID, as can happen if lvm snapshots (which obviously have the same filesystem GUID as the original) are taken and both the snapshot and the source are exposed to btrfs device scan (which is auto-triggered by udev when the new device appears), with one of them mounted. Presumably you'd consider lvm snapshotting a form of mirroring and you've already said you're not doing that in any form, but just in case, because this is a rather obscure trap people using lvm could find themselves in, without a clue as to the danger, and the resulting symptoms could be rather hard to troubleshoot if this possibility wasn't considered. -- 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
