Re: fsck: to repair or not to repair

[Chris Murphy <lists@colorremedies.com>]

On Fri, May 13, 2016 at 9:28 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
> On May 13 2016, Duncan <1i5t5.duncan@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.

-- 
Chris Murphy