On May 13 2016, Duncan <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
