Re: BTRFS messes up snapshot LV with origin

[Chris Murphy <lists@colorremedies.com>]

On Sat, Nov 29, 2014 at 1:20 AM, Robert White <rwhite@pobox.com> wrote:
> On 11/28/2014 11:29 PM, Duncan wrote:
>>
>> Since I can't/won't run pretty much anything proprietary, there's little
>> chance of it being taken as anything but Linux, here.  (Tho I actually
>> use (c)gdisk for partitioning here and it appears to use a different GUID.
>> (0700 in its short form which AFAIK is gdisk specific, for MS basic data,
>> while it uses 8300 for general Linux filesystems.  I could look up the
>> long form GUIDs, but meh...)
>
>
> Partition type codes (e.g. 0700, 8300, EF00, etc) have _nothing_ to do with
> UUIDs. They are type codes. They aren't "short form" of anything else at
> all. In fact 0700 is the _long_ _form_ of the original code of "7", but in
> big-endian order now that it went from one byte to two.

No that's not correct. These four digit type codes are a user facing
friendly type code, the actual on-disk "partitiontype GUID" is a UUID
in that at the time of creation that UUID followed RFC 4122 so it was
unique: no one else was using the UUID. That UUID in the context of a
partitiontype GUID is intended to describe the purpose of that
partition: what OS, what file system, where it should mount or be used
for, etc. This is elaborately detailed in the GPT (GUID partition
table) portion of the UEFI specification. A 120 bit type code is
rather difficult for humans to remember and interact with, hence gdisk
and recently fdisk now use a four digit type code as a front end for
the partitiontypeGUID. The selection of four digits was to account for
the fact there are many many many more type codes now possible,
essentially unlimited.

This is a case where UUID are reused effectively.



> Microsoft started using pre-assigned UUIDs as "classes", e.g. type codes
> they could cram into their various registry files. If you actually read the
> registry you'll find a lot of places where "rational word" is defined as
> {some_uuid_here} and then eslwere {some_uuid_here} has a bunch of data items
> attached to it.
>
> So gpartd didn;t "reuse" microsoft UUIDs.

GNU parted absolutely re-used partitiontypeGUID
EBD0A0A2-B9E5-4433-87C0-68B6B72699C for Linux, by default. This you
know as gdisk (and friends) type code 0700. It's the same thing as
using type code 07 on an MBR partitioned disk instead of 83. It's
ridiculous that this happened considering we had distinction on MBR
with limited type code availability, and on GPT with unlimited type
codes the decision was to use an already existing type code,
EBD0A0A2-B9E5-4433-87C0-68B6B72699C.

http://www.rodsbooks.com/linux-fs-code/

The Linux partitiontype GUID is now
0FC63DAF-8483-4772-8E79-3D69D8477DE4. And actually some others have
been created also for encryption, RAID, LVM, swap, and a pile of GUIDs
from the 'discoverable partitions spec' hosted at freedesktop.org for
autodiscovery by systemd. Only very recent versions of parted supports
code 0FC63DAF-8483-4772-8E79-3D69D8477DE4.


> All this stuff has historical reasons. GNU/Linux attempts to be an
> egalitarian actor so it adapts to whatever you do.

With respect to this particular reuse of a Windows type code, it did a
total face plant on adaptation. The very decision to reuse that GUID
was a huge, weird mistake that we'll live with for years to come. Data
loss will result from it. And then it was made worse, upon recognition
that the conflict was probably not a good idea, to undermine patching
GNU parted in a timely manner. The patch to fix the problem, from the
gdisk author, sat around for two years before parted upstream merged
it. There really isn't good diplomatic language to use for this. Some
people flat out dropped the ball, and just didn't give a crap.

-- 
Chris Murphy