On May 13 2016, Duncan <1i5t5.dun...@cox.net> wrote: > Because btrfs can be multi-device, it needs some way to track which > devices belong to each filesystem, and it uses filesystem UUID for this > purpose. > > If you clone a filesystem (for instance using dd or lvm snapshotting, > doesn't matter how) and then trigger a btrfs device scan, say by plugging > in some other device with btrfs on it so udev triggers a scan, and the > kernel sees multiple devices with the same filesystem UUID as a result, > and one of those happens to be mounted, you can corrupt both copies as > the kernel btrfs won't be able to tell them apart and may write updates > to the wrong one.
That seems like a rather odd design. Why isn't btrfs refusing to mount in this situation? In the face of ambiguity, guessing is generally bad idea (at least for a computer program). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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