On 2015-12-15 09:42, Hugo Mills wrote:
On Tue, Dec 15, 2015 at 09:27:12AM -0500, Austin S. Hemmelgarn wrote:
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
<ahferro...@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?
Well, given a bunch of block devices, how do you identify which
ones to use for each of the (unknown number of) filesystems in the
system?
You can either use some kind of config file, which is going to get
out of date as device enumeration orders change or as devices are
added/deleted from the FS, or you can try to identify the devices that
belong together automatically in some way. btrfs uses the latter
option (with the former option kind of supported using the device=
mount option). The use of a UUID isn't fundamental to the latter
process, but anything that you replaced the UUID with would have the
same issues that we're seeing here -- make a duplicate of the device
at the block level, and you get additional devices that look like they
should be part of the FS.
The question is not how you avoid duplicating the UUIDs, but how
you identify that there are duplicates present, and how you deal with
that issue once you've detected them. This is complicated by the fact
that it's perfectly legitimate to have two block devices in the system
that identify themselves as the same device for the same filesystem --
this happens when they're different views of the same underlying
storage through multipathing.
I would suggest trying to migrate to a state where detecting more
than one device with the same UUID and devid is cause to prevent the
FS from mounting, unless there's also a "mount_duplicates_yes_i_
know_this_is_dangerous_and_i_know_what_im_doing" mount flag present,
for the multipathing people. That will break existing userspace
behaviour for the multipathing case, but the migration can probably be
managed. (e.g. NFS has successfully changed default behaviour for one
of its mount options in the last few(?) years).
May I propose the alternative option of adding a flag to tell mount to
_only_ use the devices specified in the options? That would allow
people to work around the common issues (multipath, dm-cache, etc), and
would provide people who have stable device enumeration to mitigate the
possibility of an attack.
--
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
