Re: attacking btrfs filesystems via UUID collisions?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2015-12-15 09:18, Hugo Mills wrote:
> On Tue, Dec 15, 2015 at 08:54:01AM -0500, Austin S. Hemmelgarn wrote:
>> On 2015-12-14 16:26, Chris Murphy wrote:
>>> On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn
>>> <ahferroin7@gmail.com> wrote:
>>>>
>>>> Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't
>>>> making a valid argument.  The fact that there is software that doesn't
>>>> handle it well would say to me based on established practice that that
>>>> software is what's broken, not common practice.
>>>
>>> The automobile is invented and due to the ensuing chaos, common
>>> practice of doing whatever the F you wanted came to an end in favor of
>>> rules of the road and traffic lights. I'm sure some people went
>>> ballistic, but for the most part things were much better without the
>>> brokenness or prior common practice.
>> Except for one thing:  Automobiles actually provide a measurable
>> significant benefit to society.  What specific benefit does
>> embedding the filesystem UUID in the metadata actually provide?
>
>     That one's easy to answer. It deals with a major issue that
> reiserfs had: if you have a filesystem with another filesystem image
> stored on it, reiserfsck could end up deciding that both the metadata
> blocks of the main filesystem *and* the metadata blocks of the image
> were part of the same FS (because they're on the same block device),
> and so would splice both filesystems into one, generally complaining
> loudly along the way that there was a lot of corruption present that
> it was trying to fix.
IIRC, that was because of the way the SB was designed, and is why other 
filesystems have a UUID in the superblock.

I probably should have been clearer with my statement, what I meant was:
What specific benefit does using the UUID for multi-device filesystems 
to identify the various devices provide?