16.05.2016 14:17, Austin S. Hemmelgarn пишет: > 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.
First, how do you know that devices, passed as device= options, are correct? Is it possible to detect stale copy? Second, today udev rules will run equivalent of "btrfs device ready" for each device that is part of btrfs. So you still need to handle the situation when device(s) appear and disappear after initial mount and have some way to distinguish between two copies. Third, what exactly "extra devices detected" means? Who is responsible for detection? Where this information is kept? How can mount query this information? > 2. Otherwise, refuse to mount and log a warning. So no way to mount degraded redundant filesystem? -- 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
