On 2016-05-13 17:35, Chris Murphy wrote:
On Fri, May 13, 2016 at 9:28 AM, Nikolaus Rath <nikol...@rath.org> wrote:
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).
The logic you describe requires code. It's the absence of code rather
than an intentional design that's the cause of the current behavior.
And yes, it'd be nice if Btrfs weren't stepping on its own tail in
this situation. It could be as simple as refusing to mount anytime
there's an ambiguity, but that's sorta user hostile if there isn't a
message that goes along with it to help the user figure out a way to
resolve the problem. And that too could be fraught with peril if the
user makes a mistake. So, really what's the right way to do this is
part of the problem but I agree it's better to be hostile and refuse
to mount a given volume UUID at all when too many devices are found,
than corrupt the file system.
FWIW, the behavior I'd expect from a sysadmin perspective would be:
1. If and only if a correct number of device= options have been passed
to mount, use those devices (and only those devices), and log a warning
if extra devices are detected.
2. Otherwise, refuse to mount and log a warning.
--
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
