Re: [PATCH 3/3] Don't pass md array UUID as member format UUID.

[Anne Mulhern]

----- Original Message -----
> From: "David Lehman" 
> To: [e-mail]
> Sent: Friday, August 1, 2014 6:46:19 PM
> Subject: Re: [PATCH 3/3] Don't pass md array UUID as member format UUID.
>
> On 08/01/2014 03:35 AM, Anne Mulhern wrote:
> > ----- Original Message -----
> > > From: "David Lehman" 
> > > To: [e-mail]
> > > Sent: Friday, August 1, 2014 12:16:04 AM
> > > Subject: [PATCH 3/3] Don't pass md array UUID as member format UUID.
> > > Related: rhbz#1070095
> > >
> > > blivet/devicetree.py | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/blivet/devicetree.py b/blivet/devicetree.py
> > > index 73558df..03da94f 100644
> > > --- a/blivet/devicetree.py
> > > +++ b/blivet/devicetree.py
> > > @@ -1806,7 +1806,7 @@ class DeviceTree(object):
> > >           # attempt to reset the uuid using mdexamine info
> > >           # will succeed only if metadata version > 0.90
> > >        kwargs["uuid"] = udev.device_get_md_device_uuid(info) or
> > >
> > > kwargs["uuid"]
> > >        kwargs["uuid"] = udev.device_get_md_device_uuid(info)
> > >
> > >         kwargs["biosraid"] = udev.device_is_biosraid_member(info)
> > >     elif format_type == "LVM2_member":
> > >
> > > --
> > > 1.9.3
> > >
> > > anaconda-patches mailing list
> > > [e-mail]
> > > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
> >
> > If it's really true that the value obtained from device_get_uuid()
> > is certain to be completely irrelevant here, so that we can
> > override it unconditionally, then device_get_uuid() can probably
> > be simplified to a 1-liner and maybe a comment added about the
> > nature of ID_FS_UUID (it's not clear to me what might be expected
> > to set it.)
>
> If MD_UUID was ever in the udev info for md members, it isn't anymore.
> It probably came from anaconda's udev rules.

I believe that I actually saw it pop up as a result of running the previous
pyudev code in the debugger. I can't for the life of me see any way that
mdadm could be setting it, but I do think I saw it.
> > ID_FS_UUID is the UUID of the filesystem/data on the current device. It
>
> only becomes complicated with md and btrfs because, instead of using
> ID_FS_UUID for the device-specific (and therefore unique, like a UUID
> should be) value, they use it for the container/array/volume and
> introduce ID_FS_UUID_SUB for the member-specific UUIDs. LVM (correctly)
> has the PV UUID as ID_FS_UUID of the members and then you have to look
> elsewhere for VG and/or LV UUIDs.
>
> Anyway, I was able to reduce device_get_uuid to a single line and since
> I just found out that ID_FS_UUID_SUB contains the md member-specific
> UUID I changed device_get_md_device_uuid like this:
>
> @@ -395,7 +387,9 @@ def device_get_md_device_uuid(info):
>       # Value for MD_UUID known to be obtained from:
>       #  * pyudev/libudev
>       #  * mdraid/mdadm (only 1.x metadata versions)
> return info.get('MD_DEV_UUID')
> # Value for ID_FS_UUID_SUB known to be obtained from:
> #  * pyudev/libudev
> return info.get('ID_FS_UUID_SUB') or info.get('MD_DEV_UUID')

I just realized that now that the infos are distinct that it works,
but wierdly. If you pass udev info you may get value for ID_FS_UUID_SUB,
but if md info then you may get value for MD_DEV_UUID. So, it might make
sense to pass both infos.

I'm not sure how to handle this exactly, but it does make an argument
for the notion of having a SuperCache of the kind I described in my
previous email.
> > Also, the comment should be changed to something like:
> >
> > reset the device UUID using mdexamine info
> > UUID is None if metadata version <= 0.90
> >
> > or something like that.
>
> Done.
> > mulhern
> >
> > anaconda-patches mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
>
> anaconda-patches mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches